On Sat, May 29, 2010 at 6:35 PM, Chia-I Wu <olva...@gmail.com> wrote: > Hi Jakob, > > I like the way the extensions are separated and presented. But I have some > thoughts about the entrypoints and EGL types to use. > > To begin with, I think the goal of this series of extensions is to export a > subset of pipe_screen->resource_create, pipe_screen->resource_from_handle, and > pipe_screen->resource_get_handle. That is, to allow an app to create a > single-leveled PIPE_TEXTURE_2D pipe_resource from a winsys handle or nowhere, > and to query the pipe_resource and its winsys handle. > > For pipe_screen->resource_create, we need > > * an EGL type to represent the pipe_resource > * a way to describe the resource template for resource creation > * a way to query the fields of a pipe_resource > > For pipe_screen->resource_from_handle and pipe_screen->resource_get_handle, we > need > > * a way to describe a (DRM) winsys_handle > * a way to query the winsys_handle of a pipe_resource > > > With this view, EGL_MESA_create_image, EGL_MESA_get_image_attrib, and > EGL_MESA_image_system_use > > * use EGLImageKHR to represent the pipe_resource > * use attrib_list of eglCreateImageKHR to describe the resource template > (missing description of the pipe format) > * adds a function to query the width/height of a pipe_resource > > and EGL_MESA_drm_image > > * uses attrib_list of eglCreateImageKHR to describe a DRM winsys_handle > * uses eglGetImageAttribMESA for querying > > The missing part is, if I did not overlook anything, a way to represent a > pipe_format and to query the pipe_format, which can be as simple as exporting > some of the pipe formats. > > 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 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. 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. 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. Kristian _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
