2010/6/4 Kristian Høgsberg <k...@bitplanet.net>: > 2010/6/3 Chia-I Wu <olva...@gmail.com>: >> 2010/6/3 Kristian Høgsberg <k...@bitplanet.net>: >>> 2010/6/3 Chia-I Wu <olva...@gmail.com>: >>>> 2010/6/3 Kristian Høgsberg <k...@bitplanet.net>: >>>>>> 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. I'd like to see the two functions merged. What do you think about using a struct?
As described in another mail to Jakob, eglCreateImage is to create EGLImages with sources, while eglCreateDRMImage is to create EGLImages without sources. Using a struct allows us to do processA: EGLDRMSourceMESA src; /* create a source-less image */ img = eglCreateDRMImageMESA(dpy, &src, ...); send(src); processB: src = receive(); /* create an image from EGLDRMSource */ img = eglCreateImage(..., src, ...); -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
