On Wed, 09 Dec 2009 08:19:11 -0700, Brian Paul <bri...@vmware.com> wrote:
> Eric Anholt wrote:
> > 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?
>
> I agree with that.
>
>
> > 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.
>
> We tend to keep derived state (marked with leading _underscore) for
> things that will be frequently accessed. I wouldn't do that for
> glGet() state.Yeah, rewrote it based on that. The patch came out even smaller.
pgp6v3gWTF3o3.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
