Hyperion Entertainment Message Boards

I have a simple 2D game that renders with SDL+MiniGL (Sam440ep + M9 Radeon).

Game is playable on both 16/32-bit custom screen, or 16-bit WB screen, but if I change my WB to 32-bit mode with compositing effects, frame rate drops from playable to ~2. With no compositing enabled, performance is ok.

I have debugged that the bitmaps given to MiniGL are always same format as the destination bitmap. So, in 32-bit case format is 6 and in 16-bit case format is 10.

As far as I can see, I have still plenty of VRAM still left (~30MB). Is there something that I could do on application or SDL(2) side to improve performance?

For the reference, here is SwapWindow code:

https://sourceforge.net/p/sdl2-amigaos4 ... ngl.c#l335

Same problem happened also with SDL1. http://amigaworld.net/modules/newbb/vie ... m=9#730146

EDIT: changed title

I am very interested in a solution as that also seems to be the affecting reason why some engines/games in ScummVM are awfully slow.

Raziel wrote:I am very interested in a solution as that also seems to be the affecting reason why some engines/games in ScummVM are awfully slow.

I don't see how your issue will get any attention from anyone unless you provide a link to a game that can
be tested to confirm the problem you describe.

I stopped bothering doing extra work just to get a confirmation or rejection, too much hassle as the persons in charge tend to simply ignore me...(not talking about you obviously)

I'll watch this space and draw my own conclusions

capehill wrote:I have a simple 2D game that renders with SDL+MiniGL (Sam440ep + M9 Radeon).

Game is playable on both 16/32-bit custom screen, or 16-bit WB screen, but if I change my WB to 32-bit mode with compositing effects, frame rate drops from playable to ~2. With no compositing enabled, performance is ok.

What screen resolution? Compositing effects are limited by max texture size and there may not be much head room between the screen size and the texture size, and so if window bitmaps are max screen size that might cause slow downs if the bitmaps round up to a larger than texture size. On a SAM Flex with R9250 this will happen if using FullHD, might happen earlier on a plain 440ep ?

How fast does blender run? I ask as that takes the SDL part out of the eqation amd blender shows no slow down on my SAM-Flex

Does this issue only occur on a 440ep M9 combination?

As far as I can see, I have still plenty of VRAM still left (~30MB). Is there something that I could do on application or SDL(2) side to improve performance?

I wouldn't call 30Mb plenty, more like just enough

Decided to check in on this forum for the first time in months...

broadblues wrote:

capehill wrote:I have a simple 2D game that renders with SDL+MiniGL (Sam440ep + M9 Radeon).

Game is playable on both 16/32-bit custom screen, or 16-bit WB screen, but if I change my WB to 32-bit mode with compositing effects, frame rate drops from playable to ~2. With no compositing enabled, performance is ok.

What screen resolution? Compositing effects are limited by max texture size and there may not be much head room between the screen size and the texture size, and so if window bitmaps are max screen size that might cause slow downs if the bitmaps round up to a larger than texture size. On a SAM Flex with R9250 this will happen if using FullHD, might happen earlier on a plain 440ep ?

Max compositing size is limited by the hardware's max texture size (2048x2048 on old Radeons). The frame-rate drop sounds a lot like the machine is running out of VRAM. This happens very easily with compositing enabled and graphics cards with smaller amounts of VRAM (like the Sam 440ep).

broadblues wrote:

capehill wrote: As far as I can see, I have still plenty of VRAM still left (~30MB). Is there something that I could do on application or SDL(2) side to improve performance?

I wouldn't call 30Mb plenty, more like just enough

It also depends on how fragmented the remaining 30 MB is. Warp3D allocates VRAM in large blocks. If there's block of free space large enough for the allocation, then it'll still fail and defragging and paging will occur. This means copying bitmaps to/from RAM, which is slow. Picasso96 is pretty brain-dead about choosing which bitmaps to page out, so it can page out something that will be needed again soon, causing thrashing which slows things down even more.

Remember that the ~30 MB free space includes space freed up by bitmaps/textures temporarily paged out. A 32-bit 1920x1080 bitmap alone is already ~8 MB (or 12.5% of 64MB, and 27% of 30MB)).

@capehill
Try lowering your screen resolution first to see if the frame-rate jumps back up. Game-wise, you could try reducing the size of your textures, using 16-bit instead of 32-bit textures, using compressed textures or some combination thereof.

NOTE: Texture compression is available on old Radeons only, so a fallback is needed for Radeon HD users.

Hans

Textures used by the game are quite small, 2 are 500 KB and one is 1000 KB. I could try 16-bit versions of course.

Can I somehow get some statistics from VRAM usage (fragmentation, paging)?

If graphics.library still uses an ancient pager, should there be a ticket for improving it?

...or finally support the whole gfx ram available on a gfx card, instead of only 128 MB...

I changed the WB screen to 640*480*32bit mode and game is still way too slow (like 3 FPS), when compositing is enabled. I will try to implement 16-bit textures next.

Checked also the monitor icon and interrupts are enabled. That's INTERRUPTS=Yes, right?

capehill wrote:Textures used by the game are quite small, 2 are 500 KB and one is 1000 KB. I could try 16-bit versions of course.

Can I somehow get some statistics from VRAM usage (fragmentation, paging)?

I'm afraid not.

capehill wrote:If graphics.library still uses an ancient pager, should there be a ticket for improving it?

IIRC, one already exists.

capehill wrote:I changed the WB screen to 640*480*32bit mode and game is still way too slow (like 3 FPS), when compositing is enabled. I will try to implement 16-bit textures next.

Checked also the monitor icon and interrupts are enabled. That's INTERRUPTS=Yes, right?

Yes, interrupts are enabled.

How much free VRAM do you have when the screen resolution is dropped to 640x480? With that little space taken up with textures, perhaps something else is going on. I wonder what, though, because I'm pretty sure that there's SDL based OpenGL games/software that work just fine with compositing enabled. IIRC, Neverball is SDL based...

Raziel wrote:...or finally support the whole gfx ram available on a gfx card, instead of only 128 MB...

We'll get there eventually, although that won't help users of older Radeon cards (and the Radeon M9) that genuinely have less than 256 MiB.

Hans