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. Now lets move on and try and get that image into KMS. If KMS had been a normal Khronos API we would have added a extension to that API that exported the function looking something like this "int drmModeAddFBFromEGLImage(EGLImage img, unsigned *out)", this is in line with how EGL image integration works with all other Khronos API's. Now adding that function to the KMS API is a bit tricky. We could just add it to the EGL API and I guess thats is what you suggests. But it is awfully specific to just this use case. It would be nice if we could also use this for the sharing use case and any other for that matter. Enter MESA_get_image_attrib and MESA_drm_image. The former being completely generic. And latter covering both the scanout and shareing uses with very little effort. Cheers Jakob. _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
