On Tue, 08 Dec 2009 23:38:22 -0800, Ian Romanick <i...@freedesktop.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Eric Anholt wrote:
> > ---
> > src/mesa/drivers/dri/intel/intel_buffers.c | 21 +++++++++++++++++++++
> > src/mesa/drivers/dri/intel/intel_extensions.c | 1 +
> > 2 files changed, 22 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c
> > b/src/mesa/drivers/dri/intel/intel_buffers.c
> > index 6b12d48..cee5cf6 100644
> > --- a/src/mesa/drivers/dri/intel/intel_buffers.c
> > +++ b/src/mesa/drivers/dri/intel/intel_buffers.c
> > @@ -362,6 +362,8 @@ intelDrawBuffer(GLcontext * ctx, GLenum mode)
> > static void
> > intelReadBuffer(GLcontext * ctx, GLenum mode)
> > {
> > + struct intel_renderbuffer *irb;
> > +
> > if ((ctx->DrawBuffer != NULL) && (ctx->DrawBuffer->Name == 0)) {
> > struct intel_context *const intel = intel_context(ctx);
> > const GLboolean was_front_buffer_reading =
> > @@ -390,6 +392,25 @@ intelReadBuffer(GLcontext * ctx, GLenum mode)
> > /* Generally, functions which read pixels (glReadPixels, glCopyPixels,
> > etc)
> > * reference ctx->ReadBuffer and do appropriate state checks.
> > */
> > +
> > + /* GL_OES_read_format */
> > + irb = intel_renderbuffer(ctx->ReadBuffer->_ColorReadBuffer);
> > + if (irb) {
> > + switch (irb->texformat) {
> > + case MESA_FORMAT_ARGB8888:
> > + ctx->ReadBuffer->ColorReadFormat = GL_BGRA;
> > + ctx->ReadBuffer->ColorReadType = GL_UNSIGNED_BYTE;
> > + break;
> > + case MESA_FORMAT_RGB565:
> > + ctx->ReadBuffer->ColorReadFormat = GL_BGR;
> > + ctx->ReadBuffer->ColorReadType = GL_UNSIGNED_SHORT_5_6_5_REV;
> > + break;
> > + default:
> > + ctx->ReadBuffer->ColorReadFormat = GL_RGBA;
> > + ctx->ReadBuffer->ColorReadType = GL_UNSIGNED_BYTE;
> > + break;
> > + }
> > + }
>
> After hacking around with FBOs and MESA_FORMAT_* all day long (my patch
> series is coming soon!), I think this should go in a utility function
> somewhere... perhaps in fbobject.c. For a given format, I *think* the
> preferred read format / type will be the same everywhere. Does that
> sound right?So, for our driver right now we do blits for those two formats. For others, the spans code will read them out into DataType's format, and if we report something other than that (usually ABGR8888), we'll hit the user with an extra conversion. But maybe the right answer is to report the native format and say that if going native -> native is slower than native -> abgr8888, then that should get fixed. The other question I had was whether a computed value like this really deserves to live as a field updated with state changes instead of being computed at Get time. The overall Mesa style seems to be compute it up front just in case someone asks, but that doesn't seem like a great way to get an efficient stack.
pgpG0J4ZEZRZX.pgp
Description: PGP signature
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
_______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
