On Thu, 2 Nov 2000, Stefan Seefeld wrote:
> This brings up another interesting point:
>
> what is the support for offscreen video memory allocation ?
> I'm not sure I use the correct terminology, so here is what
> I have in mind:
>
> There is often a need to double buffer content in some form,
> and map (blit) it into the screen at specific times. Of course,
> the way to do that with GGI is to allocate a set of (memory)
> visuals and work with these.
The _unaccelerated_ way.
> So, what memory are the visuals allocated from ?
System memory.
> Assuming that
> they are allocated from video memory (framebuffer ?),
They aren't.
> I'd suggest
> to think about a QoS (Quality of Service) issue: Given that video
> memory is limited, some visuals would need to be allocated on regular
> heap.
All memory_visuals already are.
> I might know when allocating visuals (drawing buffers) that some are
> updated more frequently than others, i.e. they would profit much more
> from being close to the graphic card. Is there (or could there be) any way
> to expose some policy issues like these through an API for drawable memory
> management ?
Sure. This is not such an easy task, though. Such an API
(libDirectBuffer?) would need to be able to:
* Establish a set of targets which would know about all the different
types and configurations of memory buffers available for each target
* Establish global resource pools for each (e.g. dividing up a 32MB
AGP-mapped video memory aperture into front, back, z, stencil, texture,
etc buffers)
* Know what all the tradeoffs between various resource allocation requests
are (i.e. if you double your framebuffer size, you cannot have double
buffering, or you can choose to give up your z-buffer instead)
* Be able to map abstract QoS requirement types to various combinations of
the mapped resources, in a sufficiently generic manner that there's a
_point_ to using one single API for this instead of just hardcoding the
target knowledge into the app or a specific library (e.g.
'libNvidiaRivaTNT2AGP32MB' or somesuch'.
Ideas are welcome.
> You will notice that this is an issue which I brought up a couple of
> months ago already: I'm thinking of a 'Backing Store' for berlin, i.e.
> for example for video intensive graphics, I'd like to make backups of
> the scene graph in front and behind the graphic with the high frame rate,
> such that I then don't need to traverse the scene graph on each redraw,
> but rather map the three layers (back, animated graphic, front) into the
> screen to keep it consistent with the scene graph (for example if the
> exposed region of the animation isn't regular (rectangular), or if the
> layers are translucent, such that I need to blend them together, rather
> than just blitting them in.
Think about the API and target complexity that will be necessary
to intelligently ask for what you just described.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
