On Wed, 28 Feb 2001, Brian S. Julin wrote:
>
> On Wed, 28 Feb 2001, Christoph Egger wrote:
> > But you forget one situation regarding ggiGACheck(): If it fails, how
> > do you figure out, _which_ request failed? The user can handle this
> > case in a clean way, then. That is much better than just exiting the
> > application.
>
> Yes, I did leave that out. I was thinking (badly) that the
> return value of the GACheck would be a pointer to a resource list
> containing the results. But A) people throw return values away a
> lot and that would leak memory and B) it wouldn't match the other
> GGI function return codes.
>
> Better:
> int ggiGACheck(ggi_visual *vis, *ggiResource_t req, **ggi_Resource_t result);
> int ggiGASet(ggi_visual *vis, *ggiResource_t req, **ggi_Resource_t result);
> #define GAGet(vis, result) GACheck(vis, NULL, result);
>
> Result has to be double pointer because it points to stuff
> alloced inside the function.
OK - this looks good. We can do so, as noone else comes up with a
better idea.
> > > One thing I would add though is that a lot of the features will
> > > sometimes be needed in large quantity, so we should have two
> > > quantity feilds in the resource -- the amount absolutely needed,
> > > and the maximum amount needed. That or a "SpriteSet" object to
> > > request.
> >
> > We can use a "usage_counter" for each resource and share them as
> > well. For example, ggiDoom uses the same kind of enemy again and
> > again. ggiDoom requests as much sprites as needed, but internally the
> > _image_ of the sprites are shared in VRAM or system RAM buffer.
>
> Ooh... you found a nook I hadn't gotten to... good! I had
> addressed this a bit in the "aquel, ese, este" stuff, but not
> thoroughly and I didn't describe it very well.
>
> I think the best thing to do here is to make it possible to ask
> for either the whole sprite (the hardware sprite circuitry and
> the VRAM to go with) or just the VRAM or just the circuitry. This
> is similar to the way BSE can provide a memory buffer for
> off-board preparation of data for a resource.
>
> BSE should provide for a way to point each instance of the
> circuitry at any GAlloc'ed chunk of VRAM. But by default if you
> don't ask for anything special, you get one circuit and one chunk
> of VRAM to go with it.
I think, we should libBSE there, where it is. It should know nothing
about shared resources. Even libovl and libblit knows nothing about
that. Only libGAlloc knows, WHAT the target can do. If it provides
resource-sharing, then the target of libGAlloc should handle that.
libGAlloc gets a list of requested resources. Whenever a new resource
is requested, then it checks, if the resource was requested somewhere
before. To do this, libGAlloc can do some journalling things about
already _allocated_ resources with their properties.
When the new resource was already requested before in the
_request_-list or when it _is_ already allocated, then libGalloc
checks, if the target allows to share this resource. In this case,
libGalloc increases its usage-counter, says OK and returns "just" a
pointer back to the higher level-function.
Let libovl, libblit or whatever extension libgalloc uses directly or
indirectly believe, that every resource has its own area. This makes
the implementation much easier.
Well, so far - there is one more problem: we have to discuss how to
do the "copy-on-write"-technology in their targets.
Any ideas?
> In fact, this is handy for BLTS and 3D "hardware pipelines" as
> well, because you can have more than one "engine" working on the
> same data. So maybe my "aquel, ese, este" stuff was no good, but
> it might be the start of a good idea:
>
> Basically a lot of these features have different modes or states
> they can be in. They can be stored on disk; they can be in the
> VM layer so you don't know whether they are in RAM or in SWAP;
> they can be in a DMA/AGP buffer so you know they are in RAM; they
> can be in the VRAM so you know they are already on the other side
> of the bus; and they can not only be in the VRAM but pointed to
> by the circuits that make them do whatever it is they do.
Well, basically you split the resources into three kinds:
1. Resources, which are in RAM or SWAP
2. Resources, which are in DMA/AGP buffer
3. Resources, which are VRAM
This opens some room for optimisations, when the target knows about
that.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
