----- Original Message ----- > On 12.09.2011 21:14, Jose Fonseca wrote: > > > > ----- 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 > > Well then, I think I've befriended that idea ... let's go > glReadPixels > style and add a fetch-as-float bit, but please still rename SCALED to > INT, since a lot of people working on hardware drivers will be used > to > the terminology where SCALED implies conversion.
I'd be entirely fine with that. > The extra formats would really only make sense for vertices (and > allow > for simple use of a to-hw mapping table), but it really does get > awkward > with doubles. > Initially I had though that a dvec4 attribute could be implemented as > 2 > float (i.e. typeless / no conversion) attributes - nv50, nvc0 > hardware > has to be configured that way - but from an interface perspective > this > is quite ugly. I admit I'm not very familiar how hardware currently supports native double formats. Or how likely it is for hardware to have native 4 x double register support in the future. But even if we ignore the 4 x double case, there's still the 2 x double and 1 x double vertex attributes, which can be converted to float or double depending on the VertexAttrib call. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
