BltBitMap() allocating video memory!?!

[ChrisH]

A user of the graphics module of PortablE r6 (beta) has been complaining that his program is using a lot of video memory, despite carefully telling it that images should not be stored in video memory (when he doesn't need them). Having looked into it, I arrived at the totally unexpected answer that BltBitMap() is allocating video memory!

I have been allocating bitmaps in a way which I know ensures it isn't stored in video memory: No BMF_DISPLAYABLE flag, and no friend bitmap. (Tests confirm that bitmap is not allocated in video memory.)

But it seems that as soon as I use BltBitMap() to write an image into that bitmap, then that bitmap gets (permanently!) moved into video memory. (And presumably any operation which writes into a bitmap could do exactly the same thing.)

I can understand a bitmap being moved around inside video memory (to avoid fragmentation), and even a bitmap being temporarily moved from video memory to CPU memory (due to lack of video memory), but I find it totally unexpected that a bitmap allocated in CPU memory might be moved to video memory. That doesn't happen (to my knowledge anyway) on CGFX/CyberGraphX (AROS/MOS) nor Classics (AmigaOS3). And no-one I'd ever asked on this subject had ever even hinted this might happen.

I make this post (a) to check Picasso96 is behaving correctly (i.e. check this is not a bug), and (b) warn other people from making the same mistake.


Picasso96's auto-docs are not very forthcoming on this issue, but there are a couple of brief mentions of the BMF_USERPRIVATE flag. I've made some brief experiments, and using it does seem to prevent bitmaps from being moved to video memory, so I'm guessing this what I should have been using?

[Hans]

@ChrisH

But it seems that as soon as I use BltBitMap() to write an image into that bitmap, then that bitmap gets (permanently!) moved into video memory. (And presumably any operation which writes into a bitmap could do exactly the same thing.)

I can understand a bitmap being moved around inside video memory (to avoid fragmentation), and even a bitmap being temporarily moved from video memory to CPU memory (due to lack of video memory), but I find it totally unexpected that a bitmap allocated in CPU memory might be moved to video memory. That doesn't happen (to my knowledge anyway) on CGFX/CyberGraphX (AROS/MOS) nor Classics (AmigaOS3). And no-one I'd ever asked on this subject had ever even hinted this might happen.

I make this post (a) to check Picasso96 is behaving correctly (i.e. check this is not a bug), and (b) warn other people from making the same mistake.

This is correct behaviour. Using HW acceleration for blitting is always preferred, and that requires the bitmap to be moved into VRAM on the card doing the blitting (we have no GART support, so there is no other way to map it for GPU use). Not setting the BMF_DISPLAYABLE flag doesn't explicitly ban the graphics system from shifting it to VRAM; it just says that the bitmap doesn't have to be displayable.

Picasso96's auto-docs are not very forthcoming on this issue, but there are a couple of brief mentions of the BMF_USERPRIVATE flag. I've made some brief experiments, and using it does seem to prevent bitmaps from being moved to video memory, so I'm guessing this what I should have been using?

Yes, BMF_USERPRIVATE explicitly tells Picasso96 that the bitmap should never be paged into VRAM. I think that the documentation is actually pretty explicit about this:

BMF_USERPRIVATE which returns a static fast memory user
bitmap that does not need to be locked for each access as
it will never move or be accessed by graphics board hardware.

BTW, if all you want to do with that bitmap is a simple blit to an in-VRAM bitmap, then you could always allocate a block of memory, and use WritePixelArray(). On Sam4x0 machines WritePixelArray() is even DMA accelerated. Given that you can't use HW acceleration for such bitmaps and any blitting will be slow, you should also think carefully about whether you really want/need that bitmap to be in main memory.

Hans

[Hans]

@ChrisH
Come to think of it, the documentation for BMF_USERPRIVATE should probably be shifted into the graphics library's AllocBitMap()/AllocBitMapTags() documentation. The wording could probably be improved to. For example "fast memory" is now an out-dated concept given that there is no chip memory in modern machines. I suggest that you submit an enhancement request to bugzilla.

Hans

[ChrisH]

BTW, if all you want to do with that bitmap is a simple blit to an in-VRAM bitmap, then you could always allocate a block of memory, and use WritePixelArray(). On Sam4x0 machines WritePixelArray() is even DMA accelerated.

OK. I assumed that BltBitMap() would use the fastest method, even if the source bitmap was not in video memory. I will have to do some speed tests, now that I removed this bug.

P.S. The reason I want to store bitmaps in 'CPU memory' is so that I can manually manage what bitmaps are in video memory, and thus minimise my video memory usage. On something like a 64MB Sam440 this will greatly speed it up. (I've previously mentioned how Picasso96 could be improved, such that this wouldn't be necessary, but I don't think this is the right place to discuss it...)

[ChrisH]

BTW, if all you want to do with that bitmap is a simple blit to an in-VRAM bitmap, then you could always allocate a block of memory, and use WritePixelArray(). On Sam4x0 machines WritePixelArray() is even DMA accelerated. Given that you can't use HW acceleration for such bitmaps and any blitting will be slow, you should also think carefully about whether you really want/need that bitmap to be in main memory.

I've run tests on an X1000 (with RadeonHD) and Sam440 (with built-in Radeon M9 chip), and there is negligible speed difference between a BltBitMap() call & a p96WritePixelArray() call. So it seems like BltBitMap() uses DMA anyway?

EDIT: Same result for speed test on Sam460 with RadeonHD.

[Hans]

@ChrisH

I didn't mean to suggest that only WritePixelArray() uses DMA. I'm just giving it as an alternative to using a system allocated bitmap when you want image data to be stored in RAM.

One downside to trying to do your own bitmap paging, is that Picasso96 allocates RAM for every bitmap in preparation for paging. This includes temporary paging that's done internally when performing software rendering (which is when it's important to not be wasting time with allocation/deallocation). So, you will actually end up chewing through more RAM.

Hans