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.
-Brian
------------------------------------------------------------------------------
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
