On Tue, 27 Feb 2001, Christoph Egger wrote:
> > int ggiGallocCheck(ggi_visual_t vis,
> > struct ResourceProperties *in,
> > struct ResourceProperties **out);
> ^^
> Why double-pointer? Isn't a single pointer enough?
Sorry, I think I was thinking so we can feed in either NULL or *NULL,
but for the life of me, I don't know why I thought we'd want to
do that :). Perl induced dementia.
> > Also, give the "resources" a *next member to hang a linked list
> > on. This will be needed later when we add functions to negotiate
> > multiple features and negotiate them against the video mode.
>
> I see! That makes it possible to use zbuffer, alpha-buffer and
> texture-buffer at once.
Right, and the order that the resources appear in the list is the
order of importance, so suppose you wanted to say this:
"I want to use 640x480 at the highest bit depth I can get, but I
definitely need a sprite even if it means using a lower bit depth.
And an off-screen scratch area would be nice, but is not necessary."
You would have a linked list in this order:
(Resource with type RT_SPRITE) -->
(Resource with type RT_FRAME with the ggi_mode set to 640x480/GT_AUTO) -->
(Resource with type RT_SWATCH) -->
NULL
The function that does the work might look ahead in the list for
example to choose a better VRAM layout, but it would always satisfy
the requirements of the entries at the top of the list first. You
can also put more than one RT_FRAME resource in -- this:
(Resource with type RT_SPRITE) -->
(Resource with type RT_FRAME with the ggi_mode set to 640x480/GT_8BIT) -->
(Resource with type RT_SWATCH) -->
(Resource with type RT_FRAME with the ggi_mode set to GGI_AUTO/GT_AUTO) -->
NULL
Means:
"I absolutely need a sprite, and I need at least 640x480x8, and I want
a swatch. Better than 8bit colors and more resolution would be nice,
but I prefer to have the swatch even if it means I only get 640x480x8."
> I moved this into ggiResource_t to have opaque data handling.
> To have access to multiple resources suggest to add these functions
> as API:
>
> ggiResource_t ggiGallocGetNextResource(ggiResource_t res);
Hmm... I'm not sure I follow -- what does this do? Just dereference
the next? If we want to keep things "opaque" to this level,
then just using macros somewhat like the GGIEXT_* macros should
suffice.
> > I'd see three actual internal functions (_ggigalloccheck,
> > _ggigallocset, _ggigallocget) at the core of libGalloc, which
> > would have to be implemented for each target. Implementing
> > ggiGallocCheck would look like this, using those internal
> > functions:
> >
> > struct ModeProperties {
> > struct ResourceProperties res;
> > ggi_mode mode;
> > };
>
> I moved ggi_mode mode into ggiResource as well.
Umm... well I'd be concerned that we'd start bloating really fast this
way, and every time a feature with special properties that didn't
fit came along we'd be changing the structure. Really the video
mode is just another feature.
This is a bit of a sticky situation: LibGAlloc is supposed to be a
core library, but at the same time if we don't do what you are
doing (putting everything we could possibly need into the properties),
for certain targets LibGAlloc will require the headers from many
of the extensions in order to get at the feature-specific properties
in order to compile, and if those features change APIs then the Galloc
target sublibs that implement that feature have to change. But if
we do do what you're doing, then we end up with a big data structure
that keeps breaking binary compatibility. Plainly we cannot just
keep accumulating cruft.
Really I cannot think of a good way out of this -- the feature
management has to be centralized; it would be very hard to get it
to work at all if it we tried something fancy like loading functions
in from target specific extension sublibs. That would be a mess.
I think I like what you're doing in this sense: the headers that
define the feature properties that are needed to negotiate the
feature are part of LibGAlloc, and extensions include the LibGAlloc
headers. This would make LibGAlloc able to build without the extensions
present. But rather than change the resource structure all the time,
maybe we are best off defining a bunch of unions with the common
properties, which all keep track of their size/type so they can be
copied blindly. That way when a new "frag" feature that needs a property
called "fragalisticness" has to be added, you just need to add a header
in /usr/include/galloc/extensions/frag.h, and modify just the
LibGAlloc target sublibs that support the "frag" extension to include
this file, along with the code to help them negotiate the feature on
their target.
> > Actually, the "resource" thing will probably be confused with the
> > ggiResourceAquire() function which is used to grab a directbuffer
> > away from the accelerator engine. there is already a
> > ggi_resource_t, which is awfully close to ggiResource_t.
> >
> > The RT_* stuff might end up clashing with "Real-Time" support
> > libraries at some point, but that's not too horribly likely.
>
> Hmmm... You are thinking in the same direction as I do. That's why I
> asked, if it is ok.
>
> Has anyone some suggestions for a clean namespace?
I think "caps" (capability) is politically loaded (There's some
bad association there to DirectX and "capability flags" which seem
to be unpopular), so we should not use that. That's why I was
using "Feature" before. "Aspect" has other graphical meanings,
so that's out. Maybe we should just use "thing" :-P
--
Brian
