I think we may stick to
st_api and st_context
st_manager_api and st_framebuffer
Sounds good?
On Fri, Jan 15, 2010 at 05:18:53PM +0000, Jakob Bornecrantz wrote:
> >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.
You meant the mail I sent a while ago? I now think a pipe texture might
suffice for EGLImage. That is, (pseudo code)
ptex = st_manager_api->lock_resource(ST_MANAGER_RESOURCE_EGL_IMAGE, img);
The interface for peeking the pipe texture of
EGLImage/texture object/VGImage/... might need some discussion too.
I use "lock" because eglCreatePbufferFromClientBuffer can create a
pbuffer surface from a VGImage and it will cause any access to the
VGImage in OpenVG to return VG_IMAGE_IN_USE_ERROR error. Conversely, if
the VGImage is in use by OpenVG, eglCreatePbufferFromClientBuffer should
fail with EGL_BAD_ACCESS.
I am thinking all resource peeking should be paired with lock_resource
and unlock_resource. If an extension does not imply access control, the
sequence might look like lock_resource -> increase reference count and
steal -> unlock_resource.
> >>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).
It is either called in the st manager or the st. We are moving the task
from st manager to st.
If there is a DRI2 notification mechanism someday, the st manager should
handle that, and the st manager will remember the current buffers and
know that they are up-to-date. Calling "validate" becomes cheap.
There is already notify_invalid_framebuffer. On server with such
mechanism, there is no need for st to call "validate" upon glViewport.
But to support both new and old server, it may still call "validate"
actively (remeber that it is cheap on a new 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.
See above.
> >>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 meant the necessity of st_manager_api. I think we agree we need it,
right?
> >
> >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.
OpenVG cannot control the buffer to render to. The st_framebuffer it
binds to decide the buffer (which is decided by the user through
EGL_RENDER_BUFFER).
Given two double-buffered st_framebuffers, one may have the render
buffer set to front while the other has it set to back. The same
context will render to the front buffer of the first, and to the back
buffer of the second.
The info is queryable in EGL. It is simple for OpenVG and OpenGL ES.
But for OpenGL, it may ask for both front and back buffers without st
manager knowing which buffer it renders to.
> The caps should be static variables that don't change during the
> life time of the application.
Ok. I misunderstood get_param. I think we should avoid that, but I
doubt we can.
> >
> >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.
--
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
