"Jon M. Taylor" wrote:
> > 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
why ? To be able to implement crossblits ? Can't you use a simple adapter
interface (some form of 'marshalling') ? I mean, the interesting case is
blitting from video memory to video memory, and there I assume that all
parameters (alignment etc.) are identical.
> * 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)
does this division need to be static ? Can't you have a single manager
instance which keeps track of which memory is allocated for which purpose ?
That would help in the implementation of QoS policies...
> * 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)
Right. Can't that be a simple table ? (which would indicate how much memory
the different buffer types need, etc.)
> * 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'.
Hmm. I don't know whether that is of *any* relevance. But I'm studying the
CORBA architecture, especially its historical evolution. CORBA is a middleware
architecture to provide a set of 'services', encapsulating all the nasty details
of OS dependence, transport protocols, etc.
The more CORBA evolves, the more it becomes clear that users might want to explicitely
control low level features, such as messaging strategies, concurrency strategies, etc.
Therefor, there are more and more specifications added to CORBA which allow to
control these features in terms of 'policies', 'interceptors' (some sophisticated
form of callbacks), etc.
May be it would be interesting for you to look into it, or to let us discuss this,
as I think that some general architectural principles would apply equally well
for GGI, where you try to encapsulate the OS, and video hardware, from the user,
while still trying to provide a maximum of flexibility and efficiency. In other
words, some knowledge which is needed to optimize efficiently, can't be known
while you implement GGI, so you need some cooperation from the user. The question
is how to interface this.
Best regards, Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
