On Sat, Jan 16, 2010 at 04:32:29AM +0000, Jakob Bornecrantz wrote:
> I see what the problem is, EGL configurations defer things like
> double buffering to be derived at surface creation time. For GLX
> this is a part of the config from the start. Maybe we should have
> those configureable attributes as tri state in the st_visual. Like
> true, false, dont_care.
In the st_api.h, st_context is created by state trackers with a context
visual. st_framebuffer, on the other hand, is created my the st manager
and is passed to the state trackers.
The context visual should describe the user's desire (I want a context
that can do multisampling). The framebuffer visual embedded in
st_framebuffer also describe the user's desire (I prefer the back buffer
to be rendered to).
But to allow state trackers to know the capabilities the framebuffer
without validating, infos like which buffers are available or what
formats they are in are also encoded. All these infos can be derived by
validating. By encoding them, we allow deferred allocation of the
buffers.
IMHO, context visual and fb visual are two separate things. You can
bind a context capable of multisampling to a surface without the sample
buffers. But they are unlike GLXFBConfig. GLX should give an error
when the user tries to do so.
> >Yes, that is what I have in mind. The st manager may be GLX or EGL.
> >The state tracker can always create a depth/stencil buffer if the
> >st_framebuffer does not have one. The trick here is, while EGL
> >can give
> >a st_context wanting depth/stencil buffer a st_framebuffer without
> >one,
> >GLX should not.
> No EGL can not, the context visual and drawable visual most be
> compatible this includes depth/stencil. EGL doesn't however define
> if the context have a double buffer or not, AFAIK GLX does. As I
> mentioned above I think some sort of tri state option is needed.
I think the state tracker should do something like (pseudo code):
if (stctx->want_front_buffer)
add_to_attachment_list;
if (stctx->want_back_buffer)
add_to_attachment_list;
if (stctx->want_depth_stencil)
add_to_attachment_list;
stfb->validate();
if (no depth/stencil texture)
stctx->pipe->screen->create_texture();
For GLX, it should not bind a context needing a depth buffer to a
framebuffer without one. And the create_texture will never be hit. But
EGL allows private depth/stencil buffer. It becomes an implementator's
choice.
> >Also, as an interface, I think we should list all aux buffers
> >mentioned
> >in GLX (multisample, accum, and probably more?). I don't recall EGL
> >require shareable buffers so listing those in GLX should be enough.
> Yupp sounds good.
[snipped]
> >>>I would like to see st_api->make_current take only the context to
> >>>be made
> >>>current. It means, all glFooBar calls will take the current
> >>>context as an
> >>>implicit argument. And add st_context->bind_framebuffers to bind
> >>>the draw/read
> >>>framebuffers.
> >>Is there any reason for this other then saving a single TLS lookup
> >>plus pointer comparison in the rendering API make_current? Seem
> >>totally useless otherwise.
> >make_current is, apparently, to support eglMakeCurrent and
> >glXMakeCurrent. I always think it mixes two operations together
> >and our
> >interface needs not be a strict one-one map to the API.
> Where it doesn't give any extra functionality the API should be as
> close as possible to other API's as possible so that somebody coming
> to this API with knowledge about another API knows what is going on,
> and is not confused about how function or functions. In this case we
> don't gain anything other then confusion.
I can think of some benefits. Actually, the API should be
struct st_context {
...
boolean (*bind_framebuffers)(...);
...
};
struct st_manager_api {
...
st_context (*get_current_context)(...);
...
};
After some thinking, I think this is the most natural form. The
per-thread info should be stored in st manager. The first function
gives the context the framebuffers to render to. This is what state
trackers care about. The second function allows glFooBar to be
implemented (by calling into st_manager_api to get current context).
There is no make_current or get_current_context in st_api.
But to allow fast access to current context in the state trackers, this
optional function
struct st_api {
...
/* allow st to cache current context for fast access */
boolean (*notify_current_context)(...);
...
};
can be added. MakeCurrent(draw, read, ctx) is implemented by
...
ctx->bind_framebuffers(draw, read);
if (stapi->notify_current_context)
stapi->notify_current_context(ctx);
And MakeCurrent(NULL, NULL, NULL) is implemented in st manager by
if (stapi->notify_current_context)
stapi->notify_current_context(NULL);
ctx = get_current_context();
ctx->bind_framebuffers(NULL, NULL);
There are several benefits of this design. State trackers no longer
need to handle MakeCurrent(NULL, NULL, NULL) specially. They are
handled by the st manager. And for state trackers that are too lazy to
cache the current context (which can be tedious because the current
context must be per-thread), it can call into st_manager_api.
--
Regards,
olv
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
