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?
> 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.
> 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.)
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.
> 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?
--
Brian
