On Fri, 3 Nov 2000, Stefan Seefeld wrote:
> "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 ?
No, to be able to set modes intelligently in the presence of
arbitrarily complex extensions attached to any number of visuals which
might use ggi_resources which are exposed and managed by a particular
target.
> Can't you use a simple adapter
> interface (some form of 'marshalling') ?
We already do, sort of. The target strings and the
request-strings which the KGI/kgicon targets use do something like this.
Resource request strings will presumably have the same sort of "namespace
tree" format. I've proposed a resource request hierarchy based on this
type of system before - search the archives.
> I mean, the interesting case is
> blitting from video memory to video memory,
Define "video memory". PCI and especially AGP memory mapping
tricks make this potentially quite complex. Is the memory on the card, or
system RAM mapped across the AGP GART pagetables? Is it tiled, and if so
how? Has the region been marked cacheable, and if not can it be? What
about MTRRs? The issue CAN be simplified, but not if you expect to retain
any significant degree of optimization potential.
> and there I assume that all
> parameters (alignment etc.) are identical.
Not necessarily, in the case of tiled or GART-mapped AGP aperture
memory spaces.
> > * 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 ?
It _cannot_ be static.
> Can't you have a single manager
> instance which keeps track of which memory is allocated for which purpose ?
Yes, _in the target code_. This stuff must ultimately be mapped
into some sort of target-independent resource namespace. We cannot even
assume that only one target (or target instance) is managing the whole of
the video card's resources.
> > * 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.)
Not in all cases. There are potentially many, many different
restrictions on what types of buffers can be mapped where, and in what
combinations, and all of this is highly chipset-dependent |-<.
> > * 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.
CORBA is also slow - WAY too slow for a system layer such as GGI.
We are avoiding C++ altogether because of performance issues, so CORBA
seems to be out |->.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
