On 15 jan 2010, at 02.48, Chia-I Wu wrote:
> On Fri, Jan 15, 2010 at 9:35 AM, Jakob Bornecrantz
> <ja...@vmware.com> wrote:
>> you guys are doing great work with the EGL state tracker. So I
>> thought it
>> would be a good time to open up a discussion about the way that the
>> API
>> state trackers talk to the EGL, dri and other co state trackers.
> I started some work yesterday. It is based on the patch you sent
> earlier, and
> I have a local branch that port egl_g3d and OpenVG to the new st_api
> and is
> functioning. Attached in the interface part. Note that it is still
> primitive.
>
> In the interface, "ST" stands for "state tracker and "SM" stands for
> "state
> tracker manager" or "surface manager" (i.e. EGL). There are three
> characteristics that make it different from st_public.h
>
> * the framebuffer (or surface, or drawable) is owned by SM
> * no more __GLcontextModes
> * besides struct st_api, there is struct sm_api that allows state
> trackers to
> call into the manager
>
> I think all three are important. They should be kept in mind while
> designing
> the interface. Our versions both have the first two
> characteristics, and the
> third is used to support GL_OES_EGL_image and VG_KHR_EGL_image.
I do not think that reusing the st_framebuffrer for a image is the
right idea, a EGL image is just a pipe_texture reference and a
descriptions of which level/face/zslize to use. Now sounds just like a
pipe_surface but it has some semantics attached to it that is not
suitable for image.
>> I have attached a proposed interface to be used between the
>> different state
>> trackers. I know that Chia-I and I have talked about it before and
>> nothing
>> much have changed since then. The main point of this API is to
>> eliminate the
>> last references to winsys in the gallium interface, This could be
>> done by
>> just moving update_buffer/flush_frontbuffer to pipe_screen, but
>> this is not
>> acceptable, since the pipe driver is not the one to take care of
>> those
>> things.
> I think this is solved by the new st_framebuffer or sm_surface?
Exactly, I just wanted to point out that update_buffer and
flush_frontbuffer on pipe_screen will go away.
>> Some things that needs to worked out about this interface is how to
>> handle
>> glViewport vs DRI2, since the code in glViewport needs to force a
>> update of
>> the buffers in DRI2 but not for other state trackers. If we can
>> some how
>> work around the need to force a update in a way that works on old
>> servers
>> that would be great, but I doubt that can be done.
> With the mesa/st having access to the new st_framebuffer/sm_surface,
> it can
> call validate upon glViewport. Does that suffice?
Yes it does, except calling validate is always a heavy wight operation
(a round trip to the X server).
>
> I am curious about this part too. How often does DRI2GetBuffers be
> called in
> DRI2 drivers? In egl_g3d, it is indirectly called in every
> eglSwapBuffers and
> flush_frontbuffer. There is no glViewport equivalent in OpenVG, it
> seems, so
> egl_g3d does not rely on glViewport or the equivalents being called
> to update
> the buffers. Surely, update_buffers will (it is not right now)
> still be
> hooked, but egl_g3d don't rely on it.
DRI2GetBuffers is called every glViewport and makeCurrent.
So the glViewport problem is this. The rendering API should get a
notification that it should call into the validate function. The
problem in DRI2 is that the notification is glViewport, if we can
solve that with DRI2 events thats great! The problem is that we need
to support older X servers, at least I do.
>> On the topic of EGL I'm wondering if this should be exposed in
>> st_api.h or
>> in some extra api on the side of st_api.h. To check if the API
>> supports EGL
>> one could introduce some sort of ST_CAPS that the api's can
>> communicate
>> between each other. Adding something like below to the st_api struct.
>>
>> /**
>> * Query an integer-valued capability/parameter/limit
>> * \param param one of ST_CAP_x
>> */
>> int (*get_param)(struct st_api *api, int param);
>>
>> And then base classing st_context in a st_egl_context, which is
>> guarded by a
>> ST_CAP_EGL or something:
>>
>> struct st_egl_context
>> {
>> struct st_context base;
>>
>> int egl_func1(params);
>> ...
>> };
>>
>> Currently there is not a struct that represents the co state
>> tracker in this
>> interface, mostly because there has been no need (other then the
>> flush/validate functions on the framebuffer) to call into the co
>> state
>> tracker. Maybe if exposing caps back to the rendering api we can
>> solve the
>> glViewport issue by having ST_CAP_GL_VIEWPORT_ALWAYS_VALIDATE cap,
>> a bit
>> hacky yes. But I don't think any backwards compatible solution to
>> that
>> problem would be nice.
> There is a need for state tracker to ask co state tracker to return
> the
> underlying pipe texture of an EGLImage.
See above.
>
> I think get_param might be a good idea. In EGL, user can ask what
> is the
> render buffer (front or back) of the current context and its draw
> surface. I
> add "get_render_buffer" in my version solely for that purpose.
> get_param might
> do a better job.
There should be no need for the any cross API communication of that
type. Whether a rendering API renders to the front, back, left or
right is private to the rendering API. That being said the bindings
API may look at the buffers that the rendering API requests from the
st_framebuffer and delay any creation because with the help of that.
The caps should be static variables that don't change during the life
time of the application.
>
> I don't think I get the glViewport problem. Could you tell me more
> about the
> problem?
See above.
> We might also need to unify the terms. I prefer sm (state tracker
> manager or surface manager) over co state tracker because you can
> write "struct
> sm_api" or "struct sm_surface" in C. It also emphasizes that while
> st_context
> is owned by the state tracker, sm_surface is owned by EGL. What do
> you think?
Okay, since this a internal Gallium interface old Gallium names takes
precedence.
The use of surface is a bad one since there already is a concept of
surface in gallium and it is completely different from what is in your
interface. So that leaves either st_framebuffer or st_drawable.
With that in mind calling the "co state tracker surface" manager is
bad, I kinda like manager but the big problem is that that the proper
name for it is Windowing System Bindings, winsys for short, but that
is already taken. So either st_manager_api or st_binding_api. I could
go with either one.
I also dislike having different prefixes in the interface just as all
the structs and enum in the pipe interface have the same prefix the st
interface should have the same one. There are only 5 structs it
shouldn't be that hard remember that st_framebuffer is owned by the st
manager.
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
