On 16 jan 2010, at 10.05, Chia-I Wu wrote: > On Sat, Jan 16, 2010 at 04:03:52AM +0000, Jakob Bornecrantz wrote: >>> 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. > There should be no "create_egl_image". EGLImage are created by EGL. > There needs to be two "lookup" functions, one in st_api and one in > st_manager_api.
You are right, I got the semantics backwards terrible sorry for that. > > Both glEGLImageTargetTexture2DOES and vgCreateEGLImageTargetKHR will > take EGLImage as their argument, there needs to be a lookup function > in > st_manager_api to return the pipe texture of the image. We could just define a egl struct in this or another special API for EGL since those two functions can't be used by anything other then EGL they could just poke the egl struct themselves. > > On the other hand, eglCreateImageKHR is able to take a texture object > (type GLuint), a renderbuffer object (type GLuint), or a VGImage. > There > needs to be a lookup function in st_api to return the pipe texture of > the texture object, renderbuffer object or the VG image. > > They are actually as simple as two lookup functions. Yupp sounds good to me. >>>>>> 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. > > [snipped] >>>>> >>>>> 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 > EGL allows user to specify the preferred buffer of a surface the > context > should render to. The context may or may not obey the preference. Are you referring to eglCreateWindowSurface? For pbuffer- and client surfaces it is fixed from which render buffer they us. For window surface's you define that at creation time. This translates to selecting either a double buffered visual or single buffered visual. And should either of those be unavailable EGL will know about it and then it, so either way EGL will know the behavior of the rendering API. >> 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. > It sounds fine to me. 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
