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.
Ok, yes, I see your point. > 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. I actually like this much better. The other thing I didn't like about overloading eglCreateImageKHR (and this becomes even more evident the way Jakob split up the extension) is that it's a big new generic mechanism, and I'd really like to keep it simple and specific. As far as I understand, the khronos create_image extension was abandoned because it grew out of control - feature creep. How do you feel about going with eglCreateDRMImageMESA(dpy, &name, &stride, attrib_list), where attrib list has EGL_WIDTH, EGL_HEIGHT, EGL_IMAGE_FORMAT_MESA (with format tokens) and EGL_IMAGE_USE_MESA flags for scanout/share. And eglShareDRMImageMESA(dpy, image, &name) to create a global name for the image? And we can add an enum so we can use an EGLImage with eglCreatePbufferFromClientBuffer. Kristian _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
