On Thu, Jan 14, 2010 at 4:45 PM, Luca Barbieri <l...@luca-barbieri.com> wrote: > That will work too. > If you don't have the sequence number as input, then you would have to > change the semantics so that the caller must increase their reference > count, or accept referencing and unreferencing the textures each call > (not ideal, as it is an atomic operation, and on data possibly not > otherwise recently used). > This also loses the ability to just get the current textures without > any window system call (unless you add a flag to validate for that > functionality). On X11/DRI2, you don't get _current_ buffers without calling DRI2GetBuffers (I don't read the protocol but src/glx/x11/dri2.c seems so to me). The "validate" call models the behavior.
Remember that native displays abstract the display servers. It is EGL's job to remember which buffers are rendered to by which context. As such, it might be possible to cache the textures in EGL and save DRI2 or future native displays from doing the same work. But this may be saved for a later time. I guess I will commit my patch first. You can finish the DRI2 cache work and remove the additional validate call? > Currently I don't think EGL exposes such an operation, but it may > possibly be useful for other APIs or be exposed as an extension (would > be useful for things like an EGL-based Cairo backend, that would like > to be able to bind/unbind the context around each operation without > the penalty of an X11 roundtrip each time). > Actually, would it be possibly to _not_ update the surface in > eglMakeCurrent or glViewport for double-buffered surfaces, but only do > so on eglSwapBuffers without violating the specification? It is not a requirement in EGL. Theoretically, you might be able to delay the request for buffers until the drawing commands are flushed. But I am not sure if this will work with all state trackers and pipe drivers. It may be something worthy looking into. -olv ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
