On 12.09.2011 18:41, 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.
No. If you declare a shader input as float and you use VertexAttribIPointer, you do NOT get a float, even if the shader expects it. The vertex format describes a property of the vertex fetch stage (input assembler) and determines how data is brought from a vertex buffer into vertex attribute memory / cache; what the shader does with the data is completely unrelated. > > Jose > > > > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
