On 16 jan 2010, at 02.31, Chia-I Wu wrote:
> I think we may stick to
>
> st_api and st_context
> st_manager_api and st_framebuffer
>
> Sounds good?
Perfect.
>
> 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'm very reluctant to overcomplicate the API due to a single rendering
API mixed with a single manager having crazy rules, wouldn't it be
better to make these functions OpenVG specific?
I think you are over complicating the code needed for EGL image. Lets
try to get a simple interface as possible done first without support
for EGL_image. That said everything needed for EGL should just be the
setTexImage hook and hook on st_manage_api:
struct egl_image* (*create_egl_image)(struct pipe_texture *tex, int
level, int face, int zslice);
Pipe textures are thread safe and AFAIK follow the same rules with
regard to flushing as the gallium interface gives. Also EGL_Images are
immutable (not contents) which fit well with a pipe_texture. Which
means they never need to be locked or invalidated.
>>>> 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).
Hmmm... I'm a bit undecided, but once the validation path has been
added it shouldn't be that hard to add the invalid status of the
framebuffer.
>>> 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?
Yeah st_manager_api is probably needed.
>>>
>>> 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.
If we cheat with OpenGL everything becomes a lot prettier. Its very
simple if I understand the EGL specs correctly VG and GLES both follow
strict rules as to which buffer they will render into. So the simple
rule is if there is a backbuffer use it to render to, that it. Now
since all our implementation can follow that rule there wont be any
need for a check for that (With OpenGL we just return the same result
as with GLES even if it is a lie).
>
>> 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.
Right, I'm hoping we can just cheat with OpenGL for now.
>>>
>>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
