Re: [Mesa3d-dev] shortcoming of gl_frame_buffer (GLframebuffer)?

[Philip B. <ph...@bo...>]

On Tue, Apr 29, 2003 at 03:18:35AM +0100, Matt Sealey wrote:
> > Yeah, hooks for that stuff in GLframebuffer would be a good thing too, IMO.
> 
> A good thing? Think about it. There is no real specified limit to the number
> of GL_AUXi buffers.

Eh. There are various ways to deal with that. But, AUX buffers are
*optional*. Color buffers are _mandatory_ to OpenGL, in some form or other.
So, I dont see it as that big of a deal whether GLframebuffer has
AUX hooks or not. But I think it makes sense to have hooks for the
specification-mandatory stuff.

> > The 'driver'  has to call _mesa_create_framebuffer() or whatever
> > anyway.
> > So the driver just fills in the extra information if it uses it.
> 
> What extra information? You mean it pokes at the framebuffer structure?

What do you mean "pokes at"?
It "sets the value".
Do you call setting the GLcontext->DriverCtx "poking at it" ?
or GLcontext->DrawBuffer, for that matter?

The DOS, FX, OSmesa, Windows, AND X Mesa drivers manually "poke at"
GLcontext->DrawBuffer already.
Try this some time, in Mesa/src:
grep -li 'ctx->DrawBuffer' */*.c|egrep -v '^swrast'


> Or you're allocating/mapping memory and passing them to _mesa_create_fb()?
> 
> In the former, BAD BAD Philip, this is bad.
> 
> In the latter, BAD BAD Philip. If you allocate the memory yourself, why
> hand it to Mesa at all? It won't do anything with it. Another level of
> indirection. God forbid if Mesa trashed your structure and lost the
> pointers you passed to it. How would you free them?

If mesa trashed your structure, then you have bigger problems. This is vague 
FUD on your part :-P There is the exact same "problem" with information
hung from Glcontext->DriverCtx



> > So you have those in the GLcontext, and another GLframebuffer in
> > GLXcontext... which is usually the SAME durn GLframebuffer anyway.
> 
> Well no, since.. well, it's complicated to explain. I don't want to
> type out my whole code here because I like the way the MIT style
> license lets me keep it to myself :)
> 
> Basically I don't see what the problem is. Mesa uses that structure
> to store information. It's not an object or an instance, it's just
> a handy way to collect a bunch of information and pointers to information.

GLcontext  {
      ...
      DriverMgrCtx;  /**< Points to device driver manager (optional)*/
}


GLcontext here provides a common hook for something that drivers *might*
want to use [but none of the code in Mesa5.0.1 actually uses]
yet core Mesa does not provide a common hook for something that virtually 
all drivers could use?

Okay, yours doesnt. Thats fine, do what you like in your own driver. No one 
is forcing you to use it. I'm not proposing that people be forced to
use GLcontext->DrawBuffer->colorbuffer[GL_LEFT_FRONT] instead of
    GLcontext->DriverCtx->colorbuffer[GL_LEFT_FRONT]
or whatever the name would be. What I'm proposing is that it makes sense
to adjust the the common Mesa structs to allow this, instead of needlessly
forcing duplication of GLframebuffer structs in GLcontext->DriverCtx.



> > But I think it makes sense to provide hooks for something you KNOW all
> > drivers need. Right now, Mesa seems to go 95% of the way there. I'm
> > suggesting it provide data slot hooks for stuff that is known to be 
> > required for all OpenGL implementations.
> 
> You're changing about 5% of a 5% problem which will cause trouble for
> everyone until you change the other 95% to make Mesa 100% there.

No, the change I'm proposing will break no one's code. It will be an invisible 
change to you; if you dont use it, it wont affect you.

> Personally I won't alter my driver to use the internal pointers. Why
> bother? I don't think anyone is going to go through and change the
> exisiting drivers to do it either.

I would volunteer to do it, if the proposal was accepted, and people wanted
to see the existing MesaLib-5.x code updated.

> Again, why bother? So it's more neat?

Code consolidation. And consistency. All "framebuffer" related data, should
be contained in the "framebuffer" struct.


> GLframebuffer is private magic, isn't it?

Is it?

I dont see any documentation/API spec on it, so until I see some commentary
on it from Brian, I dont see it that way.
If there was actual documentation on writing a Mesa driver, and that
doc said, "drivers should only directly manipulate data in their
 own private GLcontext->DriverCtx struct", then thats what I
would stick to. 
But there is no documentation to that effect.


> This is why _mesa_create_framebuffer() exists. All it does is
> accept a bunch of arguments from a structure filled by
> _mesa_create_visual(), which accepts arguments to fill a
> structure, which allocates components as you ask for them.
> 
> Consolidation, simple as that.

I think it is odd that you seem to be in favour of "consolidation",
yet the main reason my proposal should be considered is for just that:
 consolidation.




> > I would have to disagree, somewhat. "GLbuffers" sounds about right,
> 
> And what distinguishes it between a framebuffer or a zbuffer or even
> something totally unrelated - for instance, a vertex buffer or a
> dma buffer?

Oops. Good point. Buffer is a rather overloaded term in OpenGL, I guess.
Erm.. except that I thought the term was "vertex array"? 
And core Mesa has nothing to do with "dma buffer". 

Hmm. After refreshing my memory by going back to the spec,
the OpenGL 1.1 version and later versions all the way up to 1.4
describe the collection of buffer info, as "the framebuffer".
I guess I withdraw my inquiry about choice of names for GLframebuffer
:-)

But if you note, the specification describes things a,b,c, etc.  as
part of "the framebuffer" information, and one of those things is
"the color buffer". So it would be consistant with the GL specification 
itself, to have a hook for color buffer info in there.
If you're gonna name an object after a specification concept, doesnt it
make sense to have the object fully model the spec?

> Maybe this whole issue would be sorted out better by some
> documentation on how to write a driver, and not wildly restructuring
> Mesa just so that the names look nicer when you read the code.

Well, docs would certainly be nice too :-) But there's something to be said 
for providing an easy-to-use API as well.
It aids code understanding. It aids debugging. It aids porting. 

The last is why I'm interested in having the generic stuff as clean as
possible.  I'm starting from the software-fallback level FIRST, and then
planning to incrementally (re)add in the hardware layers. That way, there is 
always a software fallback to verify output against.

[Technically, I'm "porting" from mesa3, to mesa5. But I'm doing a whole lot
 of weeding in the process, almost starting from a clean slate initially.]


> > I understand your pain. I'm in the middle of a massive redesign related
> > to Mesa myself. That's why I'm looking at all this stuff in the first
> > place.
> 
> I think it's pretty well okay right now. There are certainly worse
> parts of Mesa than a few semantic niggles like this, and where we
> store our driver-specific data.

I'll comment on them later, as I find them. One bit at a time ;-)


> ...
> Doing a DRI where we can somehow magically interlock and read each
> other's symbols is insane on our platform.

I'm... Ummm... not going to comment on DRI code here :-)



> I don't see the point of giving Mesa this pointer to a framebuffer,
> or single-pixel writing functions, or "generic" spanning routines,
> when Mesa doesn't ever ever ever use them, call them, act on them as 
> callbacks itself..?

The generic span routines are used by Mesa, if the driver writer chooses to 
use them, so your paragraph is inaccurate.



> Why even bother? Isn't there some more fundamental work
> in Mesa you could be doing? :)

This IS "fundamental work in Mesa" :-)
Right now, I have the choice of making my prospective code more ugly,
or of coaxing Mesa into being a little more generics-friendly.
The first option only benefits my project, and also makes 
the code less readable.
The second option helps a wider audience, while also not hindering the 
existing Mesa audience. It doesnt stop you doing what you are doing now.

It sounds like you chose the first option, because you wanted to
keep all your code private.

I'm trying for the second option. I would like to maximize the global
benefit of the hours of coding work ahead of me.