----- Original Message ----- > Am 12.09.2011 19:05, schrieb Christoph Bumiller: > > 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. > > Ah I see the problem now. This boils down to the implicit > convert-to-float which earlier GL (and hw) did, but you most likely > don't want (well the non-normalizing case) if you support native > integers (but you still need to be able to do it for GL).
Exactly, but not just int-as-float + native integer support + VertexAttribIPointer There's also GL 4's double-as-float + native double support + VertexAttribLPointer > I think the > non-normalized ints-as-floats is something d3d10 ditched. > I'm not really too thrilled seeing more formats which are essentially > the same (as the values don't actually change it's just float vs. int > type) but it seems GL actually wants this and hw can actually do it, > so > I don't really see a better solution. I guess it would be possible to > make the int-as-float bit part of the pipe_vertex_buffer or something > instead but I'm not sure it would work nicely. I'd still think an additional state in pipe_vertex_element is by far preferable to the duplication of formats. I'd like us to make a honest attempt at that. Maybe a single flag "as-float" would do it. Otherwise we might as well just start naming the formats as PIPE_foo_INT_WHATEVER, PIPE_foo_INT_I_REALLY_MEANT_IT_NOW, PIPE_foo_DOUBLE_BUT_NOT_QUITE, and PIPE_foo_DOUBLE_DONT_YOU_DARE_DOWNCAST_TO_FLOAT_OR_THE_BOOGIE_MAN_WILL_GET_YOU! :DDD Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
