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