Different surface types
brian.paul at tungstengraphics.com
Sat Apr 30 16:23:59 PDT 2005
Jon Smirl wrote:
> On 4/30/05, Brian Paul <brian.paul at tungstengraphics.com> wrote:
>>Jon Smirl wrote:
>>>On 4/30/05, Brian Paul <brian.paul at tungstengraphics.com> wrote:
>>>>>Would the standalone world be simpler if there was just one kind of
>>>>>surface that migrated to VRAM if it is going to be used?
>>>>I don't know. But I like the idea of separate types/functions for
>>>>Pbuffers and screen surfaces because PBuffers have traditionally
>>>>always been known as off-screen surfaces and there's some pbuffer
>>>>operations (such as binding to textures) which don't seem appropriate
>>>>for screen surfaces.
>>>Why can't a screen surface be bound as a texture, for example a screen
>>I imagine that could be done with some hardware, but perhaps not with
>>others (for all sorts of reasons).
>>If you want to explore how this could be accomodated with
>>EGL_MESA_screen_surface, feel free. The existing EGL functions for
>>binding texture images to surfaces don't appear to to prevent this. A
>>layered extension such as EGL_MESA_screen_texture could expose the
>>capability with little or no new API additions.
> Didn't OpenGL just add FrameBufferObjects as a generic object form
> instead of having all of the specialized objects?
Kind of. The details of how the XGL system will be able to
convert/bind application drawing surfaces as textures. There's the
business of the XGL server (a separate process) being able to
name/address application drawing surfaces. It may be that XGL might
more easily be able to do the surface/texture tricks using the EGL API
instead of GL_EXT_framebuffer_object. That's a whole other discussion
I'd rather not get into in this thread.
> Should the surface creation functions be changed to return a generic
> eglSurface type? Then you could try and use the surface in any
> function without casting. If the surface is not compatible you would
> get an error.
Are you asking for something new?
The eglCreateWindow/Pixmap/Pbuffer/ScreenSurface() functions all
return EGLSurface handles. A function like eglSwapBuffers takes an
EGLSurface but no-ops if it's not a window surface. Other
surface-related functions could generate EGL_BAD_SURFACE if needed.
I'd have to check the EGL spec to know if there's already instances of
> For example on PC class video hardware there is no difference between
> screen and pbuffers, or is there? Can pbuffers live in AGP space on
> some hardware? You might want to create a pbuffer with
> CreateScreenSurface to force it into VRAM instead of AGP.
I don't understand the last sentence. Pbuffers aren't created with
eglCreateScreenSurfaceMESA(). Do you mean surfaces in general?
More information about the dri-egl