On Thu, 1 Mar 2001, Christoph Egger wrote:
> > 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. :)
No, this was clear. What was bothering me was that one resource
could refer to another, which could make implementing GAlloc very hairy.
But I see this is going to be necessary anyway, because I just read
your last sample header more closely.
When you took the Z-buffer/Alpha enums and moved them to a subtype of
a type, instead of bitflags, that was a good move, because the res_type was
getting crowded anyway and it is bad to have an ALPHA API with a crowded
field :)
But this means to figure out what resource the Z-buffer or Alpha belongs
to (usually but not always the main framebuffer) we will have to have these
refer to another resource. I have proposed some stuff to help this below,
but let us try to keep such references 1-deep, OK?
> > 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.
I will wait to be convinced, then :).
> I think, using an additional flag in res_type is enough to let the
> target know everything to handle the resource.
I am totally braindead -- obviously these belonged in the new
res_opt feild. How does the following feel to you:
enum GA_Storage_type {
/* Doesn't matter how the resource is stored. */
GA_STORAGE_DONTCARE = 0x00000000,
/* On disk or other slow device. */
GA_STORAGE_SECONDARY = 0x00000001,
/* Offboard storage in swap or RAM. */
GA_STORAGE_VIRT = 0x00000002,
/* Data is stored in a physical RAM buffer */
GA_STORAGE_RAM = 0x00000004,
/* capable of hardware accelerated transfer to the card */
GA_STORAGE_TRANSFER = 0x00000008,
/* capable of MMIO or other direct random access */
GA_STORAGE_DIRECT = 0x00000010,
/* Onboard storage -- data is on the other side of the BUS */
GA_STORAGE_VRAM = 0x00000020,
GA_STORAGE_READONLY = 0x00000040,
GA_STORAGE_COPYONWRITE = 0x00000080,
/* This isn't storage, it's something that uses or consumes
the resource. */
GA_STORAGE_ENGINE = 0x10000000
}
/* Behavior control information between Galloc/higher level. */
enum GA_resource_state {
/* Bits that are used to talk to Galloc */
GA_STATE_REQUEST_MASK 0x00000013,
/* Bits Galloc uses to talk back to caller. */
GA_STATE_RESPONSE_MASK 0x0000001c,
/* This resource is in-service and must not be disturbed. */
GA_STATE_NORESET = 0x00000001,
/* Don't bother modifying this resource, if it fails as is, it fails.*/
GA_STATE_NOCHANGE = 0x00000002,
/* This resource request was altered due to failure or GGI_AUTO */
GA_STATE_MODIFIED = 0x00000004,
/* This resource request failed. */
GA_STATE_FAILED = 0x00000008,
/* This resource modifies or refers to the last resource in the
list that did not have this flag set. */
GA_STATE_SEEABOVE 0x00000010,
};
struct GA_ResourceProperties {
enum GA_resource_type rtype;
enum GA_storage_type storage_need, storage_ok;
enum GA_resource_state rstate;
[...]
> P.S.: Hey list! This discussion is NOT intended to be a private one
> between Brian and me! :) You can give arguements as well!
Please... Chris and I are going to actually start getting sick
of each other soon :). At least someone else say that they are
following and we haven't just created some confusing mush that
noone but us will ever understand...
Chris -- If I send you a sample but "working" implementation of GAlloc
based on the current discussion tonight, but with feature-specific
resource structures, would that help sell you on the idea?
--
Brian
