Does Odyssey use graphics memory above the 256MB?

Doesn Odyssey use the available graphics above the first 256MB for the drawing of the webpages? If not is it possible?

From my tests here seems that it doesn't and when the 256MB are filled the system starts to have stability issues.

No, it doesn't

@walkero

If it uses graphic card memory for bitmaps, it can use a lot of memory.

But its slow to move bitmaps video ram into system ram, so often you end up with two copies, one in system ram and one in video memory.

the issue is text rendering, this is done by the CPU.

@LiveForIt
Sorry, maybe I didn't explain it right. I am not talking about the system ram but the graphics card. By default AmigaOS Radeon drivers see only the first 256MB of a gfx card, but since Radeon v2 drivers it is possible to access the rest of the memory as well.

As much as I know, right now some games use that memory, and I wonder if it is possible for Odyssey to use so to not have this barrier.

@walkero

Only games relying on Warp3D SI and Warp3D Nova. Odyssey doesn't use Warp3D nor Warp3D Nova.

So my answer is still valid : no it doesn't.

And BTW, graphic memory is not used by Odyssey (well, very few actually).

You real question should be : how could Odyssey use more than the maximum displayed memory (more than 2 GB) ?

So the real question now is why?

@All

OS itself does not provide any real normal way to use more than 2GB of RAM memory (in general it's even ~1.7GB of memory, because 256mb taken for VRAM, and other bits for all sort of necessary stuff for the os itself).

All those hacks added of late like "Extended memory", are a nightmare, and the same as it was in the old DOS era where you need to use "extended memory" via some kind of bank switching. As far as I know, only Andy uses it in Sketchblock.

I.e. you can't just compile things, and have automatically working extended memory. All the functions such as memcpy(),memmove(),strcpy(),memcopy() and whatever else used by any project (in our case in WebKit), do not use it, for that dunno what needs to be done, newlib or clib2 updated, or is simply not possible dunno. The main point: extended memory (the same as the "swap", by the way), are of no real usage on os4, and dunno why there was work spend on at all. It's of no real use not for developers, not for end-users. Yes, Andy uses extended memory for Sketchblock, but probably for some specific cases only, and, as far as I remember he has all sorts of issues till he made it be working, and not sure if at this stage it working as expected.


Another question about video memory of graphics cards: the barrier of past 256 MB for video memory (GPU one, from the video card, not for the system memory), is gone past only for loaded data to. I.e. for textures going to VRAM. Like, you start a game, and the game needs 500 MB of textures being in the video memory => so that works now, and didn't feel the whole VRAM. But that just for warp3dnova drivers, and apps using it, of course. So it's not like "memcpy()" will then use that memory for any stuff we need.

With OS4 (or any other 32 (31 to be more exact) ) OS you always will be limited by that 2GB of memory, + workarounds and hacks to have more.

@Kamelito
Quote:

Why what? If you about WebKit: it's done like it was done by developers of WebKit, who give a fuck about Amiga's memory issues. If you about OS: then it's 31 bit OS :)

@Walkero
Quote:

Only by war3dnova, and only for some specific cases (like uploading of the data (textures), not any kind of data, and memcpy didn't work over of course too).

Besides that, we all need to remember, that we don't have DMA in 2020 for basic operations in graphics card drivers, not in graphics. library (at least for x5000), so using for "system app" all those 3d APIs will only make things worse and slower.

@kas1e

Quote:
One reason, I think, is that the feature is not all too well documented, with code examples showing how to use it in a real-life situation. AFAIK there's only one code snippet in the wiki, and it says "This example is written without test compilation or decent formatting, be careful of typos," which is not very encouraging either.