On Thu, Jun 3, 2010 at 1:16 PM, Brian Paul <[email protected]> wrote: > Jakob Bornecrantz wrote: >> >> 2010/6/3 Chia-I Wu <[email protected]>: >>> >>> 2010/6/3 Kristian Høgsberg <[email protected]>: >>>> >>>> 2010/6/3 Chia-I Wu <[email protected]>: >>>>> >>>>> 2010/6/3 Kristian Høgsberg <[email protected]>: >>>>>>> >>>>>>> But it is less flexible IMHO. Also, I am not convinced that >>>>>>> EGLImageKHR to be >>>>>>> queryable, which is stemmed from using EGLImageKHR to represent >>>>>>> pipe_resource. >>>>>>> Using an EGLImageKHR also implies that an implementation must >>>>>>> implement >>>>>>> EGLImage in EGL/GLES/VG, where the latter seems to still miss a way >>>>>>> to render >>>>>>> into an EGLImage. Therefore, my idea is to use pbuffer to represent >>>>>>> pipe_resource. This is in line with >>>>>>> eglCreatePbufferFromClientBuffer. To be >>>>>>> precise, >>>>>> >>>>>> No, EGLImage is the right abstraction for this. An EGLImage is a >>>>>> two-dimensional pixel array, which is exactly what we need here, since >>>>>> it corresponds directly with what a DRM buffer is. A pbuffer has more >>>>>> state, such as depth and stencil buffers. The whole point of this >>>>>> extension was to be able to use a DRM buffer as an FBO renderbuffer. >>>>>> My eglkms example doesn't demonstrate the main use case I have in mind >>>>>> with the EGLImage/DRM integration, which is page flipping and giving >>>>>> the application control over buffers. The idea is that the >>>>>> application can allocate two EGLImages for double buffering and >>>>>> alternate between attaching the two EGLImages as render buffers for an >>>>>> FBO. >>>>> >>>>> The extensions I proposed, and also the patches, allow creating >>>>> EGLImages from >>>>> pbuffers. Pbuffers have more states and this allows them to be used >>>>> with >>>>> eglMakeCurrent, other than as FBO attachments. >>>>>> >>>>>> The application is free to allocate more buffers for triple buffering >>>>>> or to discard the back buffer and depth buffer if rendering goes idle. >>>>>> The lifecycle of the EGLImage isn't tied to the lifecycle of the FBO >>>>>> the way the pbuffer colorbuffer lifecycle is tied to the pbuffers. >>>>> >>>>> Creating an EGLImage from a pbuffer would extend the lifetime of the >>>>> pbuffer >>>>> the way an EGLImage extends the lifetime of a native pixmap or a >>>>> texture >>>>> object. >>>>>> >>>>>> Also, using EGLConfig to describe the pixel format doesn't actaully >>>>>> describe the layout of the pixels. We need a precise description, >>>>>> similar to the MESA_FORMAT_* tokens. >>>>> >>>>> The idea is to use EGLConfig for creation, and add querys for >>>>> orthogonal >>>>> attributes of a pixel format such as the channel sizes, channel order, >>>>> and etc. >>>>> The precise description may be derived from the querying results. This >>>>> is to >>>>> avoid listing each format, but I do not have a strong opinion here. >>>> >>>> There is really only a handful of formats that we care about and >>>> having all this query machinery to go through just to get to the >>>> equivalent of MESA_FORMAT_ARGB8888 seems awkward. >>>> >>>>>> If VG is an important use case for you and the lack of EGLImage >>>>>> integration is a problem, I suggest defining an extension to specify >>>>>> EGLImage use in VG instead. Or we can add both, but just the pbuffer >>>>>> approach isn't sufficient. >>>>> >>>>> Pbuffer approach is like applying s/EGLImage/EGLSurface/ on EGLImage >>>>> approach, >>>>> plus allowing an EGLImage to be created from a pbuffer. This makes it >>>>> a >>>>> superset instead. >>>> >>>> I don't want to create an full EGLSurface when all I need is an >>>> EGLImage. I know I can create an EGLImage from the surface and then >>>> destroy the surface, but don't you think that's backwards? We can add >>>> an extension that lets you create an EGL pbuffer surface from an >>>> EGLImage if you need a surface for VG. What is your concern about >>>> eglQueryImage exactly? >>> >>> Existing EGLImage extensions create an EGLImage from an existing >>> resource. >>> eglQueryImage is needed in the new extension because it does not follow >>> this >>> practice. That bothers me. >>> >>> There are other ways to achieve the same goal while not breaking the >>> practice. >>> Pbuffer is one example. Using an alternative entry point such as >>> >>> img = eglCreateDRMImageKHR(dpy, &name, &stride, ...); >>> >>> is another. I do prefer these two approaches over eglQueryImage. >> >> Currently these extensions try to address two use cases. Creating >> Images to be shared between processes. Creating resources to be used >> as a scanout target. Leaving the sharing aside until later. Lets look >> at some of the problems associated with that. >> >> Resources suitable for scanout can be used as a render target and as a >> sampling source. So renderbuffer and/or texture is a good >> representation of it, it is also how we want to operate on it, but >> they are both GL objects. A EGL image however can be both of these >> objects and more and is far more flexible then a EGL surface. So lets >> use EGL image as the sharing object. >> >> The problem is that we just can't go from a any texture that happens >> to be large enough to a scanout buffer. Most hardware have stricter >> limitations on stride, tiling, placement, etc on scanout buffers then >> textures/rendertargets or those limitation make certain uses slower or >> use more memory compared to normal textures/renderbuffers. So we can't >> just go around creating all texture and renderbuffer as suitable for >> scanout just because sometime we might use it as a scanout, because it >> would be slower and use more memory. Now we don't have a way to say a >> texture/renderbuffer should be scanoutable in GL. And creating a EGL >> image from a texture/rendertarget and then mutating it into a >> scanoutable format is bad, it would effectively orphan the original >> resource unless we do major hacking in the driver which I don't want >> to do. Enter MESA_create_image and MESA_image_syste_use to solve this >> problem. Ok now we have a EGL image that can be used as a scanout and >> be shared to all the API's we want to use to render to it. > > > What's the use-case for a scanout buffer that's used as a texture? That > seems like an unusual case.
You could be pageflipping between two scanout EGLImages. If you're only rendering partial updates (using EGL_NOK_swap_region, for example) you want to copy the updated region back from the scanout buffer to the new backbuffer before rendering the next frame. Kristian _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
