-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/12/2011 11:41 AM, Jose Fonseca wrote: > > > ----- Original Message ----- >> On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger >> <srol...@vmware.com> wrote: >>> Am 11.09.2011 19:17, schrieb Dave Airlie: >>>> On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie >>>> <airl...@gmail.com> wrote: >>>>> Hi guys, >>>>> >>>>> not really finding a great explaination in my 2 minute >>>>> search, of what the USCALED and SSCALED types are >>>>> representative of >>>>> >>>>> On r600 hw at least we have a SCALED type, which seems to >>>>> be an integer in float point format, as well as an INT type >>>>> which is natural integers. >>>> >>>> Talked on irc with calim and mareko, makes sense now, need to >>>> add UINT/SINT types will document things maybe a bit more on >>>> my way past. >>>> >>>> will also rename the stencil types. >>> >>> >>> Hmm what's wrong with them? USCALED is a unsigned int type >>> which in contrast to UNORM isn't normalized but "scaled" to the >>> actual value (so same as UINT really). Same for SSCALED which >>> is just signed instead of unsigned. And the stencil types seem >>> to fit already. >> >> No, they are not. >> >> SCALED is an int that is automatically converted to float when >> fetched by a shader. >> >> The SCALED types are OpenGL's non-normalized *float* vertex >> formats that are stored in memory as ints, e.g. >> glVertexAttribPointer(... GL_INT ...). There are no SCALED >> textures or renderbuffers supported by any hardware or exposed by >> any API known to me. Radeons seem to be able to do SCALED types >> according to the ISA docs, but in practice it only works with >> vertex formats and only with SCALED8 and SCALED16 (AFAIK). >> >> Then there should be the standard INT types that are not >> converted to float upon shader reads. Those can be specified as >> vertices by glVertexAttribIPointer(... GL_INT ...) (note the >> *I*), or as integer textures. This is really missing in Gallium. > > Pipe formats describe how the data should be interpreted. > > IMO, the type of register they will be stored after interpretation > is beyond the the scope of pipe_format. I think that is purely in > the realm of shaders. > > For example, when doing texture sampling, if > PIPE_R32G32B32A32_SSCALED should be read into a integer register or > float registers should be decided by the texture sample opcode. > Not the pipe_format. > > And in the case of vertex shaders inputs, the desired register type > (float, int, double) should be not in pipe_vertex_element at all, > but probably in the shader input declaration. Given that it ties > more closely with shader itself: an integer vertex input will be > used usually with integer opcodes, and vice-versa. Independent of > the actually vertices being stored in the vertex buffer as integers > or not.
The problem is vertex shader attributes. The vertex shader may declare the attribute as a vec4, but the application may pass the data using glVertexAttribPointer(... GL_INT ...) (without the I). At least some hardware needs to be configured differently for this case than the ivec4 / glVertexAttribIPointer case. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5vgkwACgkQX1gOwKyEAw8KhgCfSlplV83Ait3CRLX36ILMlG1+ Z78AnjVrEX6oSUOgCNMbQH3NQzVJJ3Pq =LrzH -----END PGP SIGNATURE----- _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
