[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Allocation of video RAM
31 maj 2010 kl. 14.24 skrev Jo Even Skarstein:
>> The SuperVidel has 128 megs of VRAM. Blits between VRAM<>VRAM are really fast. I think that's the situation
>> with other graphics cards too. But there is no sane way to allocate such memory in an application. Not that I know of.
>
> Offscreen bitmaps perhaps? Allocation of these is handled by the VDI, and so is blits between the on- and offscreen bitmaps. So - atleast in theory - any application that use offscreen bitmaps will take advantage of the fast VRAM in the SuperVidel (or any other graphics card) if the driver handles it.
Sure. I think it's a good idea to add support for VRAM allocation for offscreen bitmaps in the VDI. But I don't think a low level memory allocation system should be implemented in the VDI, especially since I have the impression that it breaks the whole idea of memory protection.
>
>> Why shouldn't an application be able to do this? AFAIK libraries such as SDL has support for this (I may be wrong though).
>> In theory, maybe an application would like to render a texture somewhere in VRAM before it's mapped onto a polygon. Or something :)
>
> Again, this sounds like the purpose of offscreen bitmaps.
In theory, the memory could be used for other stuff as well. This is an FPGA design. And there could very well be a good reason to have low level access to a block of VRAM in the future.
It's also important to accept the fact that many coders around does not want to use the VDI. They want a framebuffer that they can draw to directly, and they may want VRAM buffers for sprites etc. Trying to force these guys into using the VDI will only put them off, and it just won't happen. They'll chose another way to do things, or ignore the platform. If there is a clean alternative which still works with the way these coders work, that clean alternative will be used.
A good example of this is the Hades. It doesn't have any low level APIs for allocation of video ram, no low level APIs for screen resolutions etc. In the end, if I want to make a 320x200x8bpp game, I have to resort to hardware banging. All because there is no API to do what I want. In the end that is such a mess that I'd rather just avoid using fullscreen graphics on that platform. And that's a pity, because it's a great machine.
-- PeP