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 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?
> 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?
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.
> 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.
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.
I don't think I get the glViewport problem. Could you tell me more about the
problem? 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?
> Thoughts and comments welcome.
>
> Cheers Jakob.
-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
