Re: [MiNT] Allocation of video RAM

[Peter Persson <pep.fishmoose@gmail.com>]

31 maj 2010 kl. 18.01 skrev Johan Klockars:

>>> Well, the advantage of offscreen bitmaps is that you can either write directly to it or have the VDI draw to it. So you can use both. You can allocate an offscreen bitmap at the size and pixel layout of the physical screen, and then point physbase to this bitmap. Then you
> can draw directly to the screen legally, and even combine it with
> using the VDI to blit
> 
> Coming from the Eclipse/RageII side, I'm very much biased against any
> kind of direct drawing to the screen. There it is at best frowned upon
> (and _slow), and at worst a recipe for disaster (as in infinite bus
> errors).
> 
> Still, I certainly understand that some people want to do it.

It's 100% necessary on a standard Falcon, I think. C2P conversions are designed to work as fast as possible towards slower video RAM. One more buffer stage means the difference between 50FPS and 15FPS, since the C2P operation is optimized to work while still copying data to STRAM (copyspeed).

If you're not using the VDI on the Falcon, things are basically done as follows:

1. Allocate a new framebuffer in ST-RAM using Mxalloc()
2. Set the physical screen address to point to that framebuffer
3. Do your thang
4. Restore the physical screen address
5. Free memory.

In this case, the application in question will have exclusive right to the framebuffer. Memory protection prevents other applications from touching it. Also, the AES can continue to do its business where the logical screen is located.

Is this clean? That's a matter of definition. The SuperVidel extends the Videl. From the coders point of view, you can still do it the way I outlined above.  Allocating video RAM in ST-RAM still means things will be slow, however. Hence there is a need to be able to allocate in faster VRAM imo.

> Quite so. I hope no one is arguing for making the lineA "blit"
> functions usable on graphics cards? On the other hand, better blit
> facilities in the VDI would be very welcome.

I'd rather peel my eyes out with a rusty spoon.

> Obviously, the VDI should do the memory mapping by calling lower level
> functions, though.

If this was implemented in the kernel, we run the risk of having a hen vs. chicken scenario :) The VDI can't allocate memory until the kernel is running? But I guess that could be overcome somehow.

>> Does fVDI have a built-in memory allocator? I've been browsing the sources for a while, and I can't find it (maybe it's too obvious and I've missed it).
> 
> If you are talking about general memory allocation, I use a pool
> allocator and a wrapper around Mxalloc(). On the RageII I have some
> very rudimentary stuff, mostly for caching icons and menu/dialog
> backgrounds, nothing generic and not usable explicitly.

Ok, I see. Not usable in this case, then.

>>> If someone wants to use VRAM for sprite buffers, can they take advantage of fast VRAM->VRAM blits without writing directly to the hardware or use some sort of driver (VDI)?
>> 
>> No of course they'll need driver functionality or some easy to use API for that, and that may very well be the VDI. But the VDI does afaik not cater for texture mapping, or even alpha blits.
> 
> But we definitely should add at least the latter. Perhaps we already
> did in ARAnyM, since we have that beautiful anti-aliased text drawing
> there, I don't recall.
> 
> Texture mapping could perhaps be made to fit into the VDI, but I have
> not looked at OpenGL etc much beyond what's used to draw 2D in ARAnyM.
> Aren't those things usually handled completely outside the 2D API's,
> though (perhaps with the 2D as a higher level layer)?

No idea tbh. And in this particular case, there is no 3D yet. Just a faster framebuffer and a new blitter.

-- PeP