On 16 jan 2010, at 02.51, Chia-I Wu wrote:
> On Fri, Jan 15, 2010 at 07:59:08PM +0000, Jakob Bornecrantz wrote:
>> I don't think that splitting st_visual is a good idea. The
>> framebuffer config needs to be able to tell the renderer if it has
>> stereo, double, depth_stencil in order for it to validate at
>> make_current time. Without having to call to validate with all the
>> attachments and therefore force the manager to create all the
>> textures.
> Some fields of st_visual will have meanings only to st_context; while
> others will have meanings only to st_framebuffer. EGL_RENDER_BUFFER
> is
> an example. It has meaning only to st_framebuffer.
>
> Or, whether a st_framebuffer has depth/stencil buffer is one thing;
> whether the context should use depth/stencil buffer is another. One
> expresses capability and the other expresses user desire.
>
> Some fields are missing in my proposal. But I still think they should
> be separate structs.
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.
>
>>>
>>>> enum st_framebuffer_attachment {
>>>> ST_SURFACE_FRONT_LEFT,
>>>> ST_SURFACE_BACK_LEFT,
>>>> ST_SURFACE_FRONT_RIGHT,
>>>> ST_SURFACE_BACK_RIGHT,
>>>> ST_SURFACE_DEPTH_STENCIL,
>>>> };
>>> In my version, there is no depth/stencil attachment. It is
>>> created by the
>>> state tracker from the pipe screen.
>>>
>>> The idea is, the display server provides only those potentially
>>> visible to the
>>> users. The depth/stencil buffer is an artifact. I am not sure if
>>> this is
>>> correct, but I would like to find out if depth/stencil is really
>>> needed to be
>>> allocated by the display server.
>> As said in later mails, depth stencil is needed for glx. One idea
>> would be to have the st manager return a NULL texture but still
>> succeed the call should it want the rendering st to create them
>> itself.
> 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.
>
> 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.
>
>>>
>>>> struct st_context
>>>> {
>>>> ............................
>>>> ............................
>>>>
>>>> int (*bind_texture)(struct st_context *ctx,
>>>> struct pipe_texture *tex,
>>>> enum st_bind_type target, int level,
>>>> enum pipe_format format);
>>>> int (*unbind_texture)(struct st_context *ctx,
>>>> struct pipe_texture *tex,
>>>> enum st_bind_type target, int level);
>>> I think this can be replaced by a single "teximage". The
>>> arguments will be
>>> very similar to glTexImage* and so do the semantics.
>>
>> Hmm okay, if that works for all the users of bind_texture/
>> unbind_texture that is fine with me.
>>
>>>
>>>> struct st_api
>>>> {
>>>> boolean (*make_current)(struct st_api *api,
>>>> struct st_context *st,
>>>> struct st_framebuffer *draw,
>>>> struct st_framebuffer *read);
>>> 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.
Cheers Jakob.
------------------------------------------------------------------------------
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
