On Thu, 1 Mar 2001, Brian S. Julin wrote:
> On Thu, 1 Mar 2001, Christoph Egger wrote:
> > > 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.
>
> Very good point.
>
> > libGAlloc gets a list of requested resources. Whenever a new resource
> > is requested, then it checks, if the resource was requested somewhere
> > before.
>
> You mean, when a VRAM resource is allocated, that we give it an ID number,
> and then you can ask for a second "engine" for the resource using that
> ID number somehow? How do you attach one "engine" to multiple VRAM
> resources using that API?
See:
> > To do this, libGAlloc can do some journalling things about
> > already _allocated_ resources with their properties.
>
> Yes, libGAlloc would maintain a target-specific data structure
> LIBGGI_GALLOCEXT(vis), that contains state about what's currently
> allocated.
Exactly. Reading a bit further before commenting gives the answer to
some questions. :)
> > 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.
>
> Hmm... I'm not sold on that yet... definitely there should be a
> very simple way to use BSE, but then I think if you're sharing
> resources, a slightly less simple API might be fine, where you
> request a "set" of X DMA/AGP buffers, Y VRAM buffers, and Z
> engines, and you have a function to point the engines at the VRAM
> buffers and to transfer between DMA/AGP RAM, VRAM, and any VM
> buffers (allocate those separately since they always must work.)
I don't think so. We can keep the API, when the properties-structure
is well-defined.
> There would also be a mode where GAlloc says "here's a chunk of
> VRAM, this feature allows you to point engines at any address in
> this chunk, and set the stride of each engine." If BSE gave that
> type of control over to the more sophisticated user I'm sure some
> people would really like that.
>
> > 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?
>
> Not right now, that's another very good point; deserves more
> thought than I can give during work.
*grin* After some thoughts about that, I think we can do this in the
targets by asking libGAlloc, _if_ the used resource is shared
_before_ write access. We have to avoid to overwrite the resource as
it can't be _really_ shared anymore, then. If the resource is shared,
then the target has to tell libGAlloc to create a real copy of it.
Note, that the properties has to be changed, when libGAlloc had to
fall back to - for example - emulate it, if no more space is
available.
As asking libGAlloc, if a resource is shared or forcing libGAlloc to
make a copy of a resource, is NOT the real job of libGAlloc, we have
to define this API somewhat "internally"...
> > 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
>
> 4. Engines and pipelines -- most of the time not visible to end user,
> but GAlloc returns them so OVL/BSE etc. know what to do.
>
> > This opens some room for optimisations, when the target knows about
> > that.
>
> Definitely.
>
> Do we add a res_mmtype, or let the subtypes have their own values
> for this in res_type, or what?
I think, using an additional flag in res_type is enough to let the
target know everything to handle the resource.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
P.S.: Hey list! This discussion is NOT intended to be a private one
between Brian and me! :) You can give arguements as well!
