Re: [MiNT] Allocation of video RAM

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

31 maj 2010 kl. 13.56 skrev Miro Kropacek:

>> My question is about video RAM (VRAM). Right now there is no functionality for this in the kernel, except Screalloc(). This means that the driver has to implement that stuff internally, which has several
> What does this function exactly? I've found only a brief description
> in tos.hyp that it allocates N bytes for screen memory (is there even
> some pointer returned?) or returns amount of available screen memory
> back.

It frees a previously allocated frame buffer and allocates a new one. It's used by Vsetscreen(), and it's not very well suited for application programs. If an application use it, that means the AES framebuffer will be freed which will lead to certain death sooner or later (since the AES will draw in memory which isn't allocated anylonger).

>> drawbacks. For example - if an application exits prematurely or doesn't do mfree() on allocated VRAM, the memory won't be freed. Furthermore, there will be no memory protection for this additional class of RAM if it isn't implemented in the kernel.
> My impression is application shouldn't call this function at all.

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.

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 :) I don't know. More thoughts on this please!

>> How difficult would it be to implement another class of RAM? Is it even feasible? And if it is - would it make sense to expand Mxalloc() to handle this new class of RAM, or would it be better to implement yet another system call for this?
> These are probably equal options, I'd personally look what OS does
> (how it allocates screen memory) to make patching as painless as
> possible. Another question is, if you want to patch TOS (in CT60
> flash) or leave this functionality to FreeMiNT/AES/fVDI (not sure what
> allocates screen memory in system).

Right now TOS handles this through Screalloc(). But it seems this function is a re-allocation function rather than an allocation function. Also, the memory allocated is global and can be touched by all applications. I don't think that should be the case if applications are allowed to allocate VRAM. Maybe the AES framebuffer could remain global, but not application memory..

-- PeP