Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ian Romanick wrote:
>> Brian Paul wrote:
>>> Ian Romanick wrote:
>>>> Why is the DataType for MESA_FORMAT_Z24_S8 and related types
>>>> GL_UNSIGNED_INT?  Right now the Intel drivers manually set the
>>>> renderbuffer DataType for these types to GL_UNSIGNED_INT_24_8 for these
>>>> formats.
>>> The renderbuffer DataType and gl_format DataType are different things.
>>> The former are related to the get/put span functions and the later 
>>> describes the format's encoding.
>>> Can you point to the specific code you're concerned with?
>> I'm looking at the handling of MESA_FORMAT_S8_Z24 in
>> intel_create_renderbuffer.  This uses has 'irb->Base.DataType =
>> GL_UNSIGNED_INT_24_8_EXT'.  There's a lot of code like this in
>> intel_fbo.c that seems like it should be replaced with calls to format
> 
> Likewise in intel_alloc_renderbuffer_storage.
> 
>> query functions supplied by format.c.

Some simplifications are possible, like:

'cpp' can be obtained with _mesa_get_format_bytes().

irb->TexFormat can be copied from rb->Format.

But rb->DataType is a little more descriptive than gl_format's 
DataType.  The later is only meant to indicate signed vs. unsigned, 
normalized vs. non-normalized and float vs. int.  But rb->DataType is 
more specific: GLubyte vs. GLushort, etc. (it's the type that the span 
get/put functions expect).

I'm not sure that part can be simplified much more.

Longer term, I want to get rid of the span get/put stuff entirely. 
Then gl_renderbuffer::DataType will probably go away.

-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

Reply via email to