[Mesa-dev] [Mesa3d-dev] r300g: hack around issue with doom3 and 0 stride

Alex Deucher alexdeucher at gmail.com
Mon Apr 12 07:56:22 PDT 2010


On Mon, Apr 12, 2010 at 10:17 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> What's wrong with the stride zero concept?
> I think most hw can handle this just fine (pretty sure all radeons
> should, though of course driver might need some special case code if it
> uses this to determine max index due to zero division). Apparently, you
> could optimize it away on nv hardware, and some hardware might not like
> it at all and hence needs to turn it into a constant, but is it really
> necessary to do away with it at a higher level?
> It might not be optimal to refetch the same vertex attribute over and
> over again, but then the app looks poorly optimized to begin with if it
> doesn't use a constant.
>

radeon hw handles zero stride just fine.  The driver just has to deal
with the 0 case properly.  E.g., in r600c:

    if(0 == pStreamDesc->stride)
    {
        nVBsize = paos->count * pStreamDesc->size *
getTypeSize(pStreamDesc->type);
    }
    else
    {
        nVBsize = (paos->count - 1) * pStreamDesc->stride
                  + pStreamDesc->size * getTypeSize(pStreamDesc->type);
    }

Alex

> Roland
>
>
> On 11.04.2010 08:54, Keith Whitwell wrote:
>> I'd like to get rid of the zero stride concept and require the state
>> tracker to either turn those values into proper constant (easy now we
>> can bind >1 constant buffer) or use instancing to get the same effect.
>>
>> Keith
>>
>>
>> On 11 Apr 2010, at 00:27, Zack Rusin <zackr at vmware.com> wrote:
>>
>>> On Saturday 10 April 2010 18:44:27 Luca Barbieri wrote:
>>>>> r300g: hack around issue with doom3 and 0 stride
>>>>>
>>>>> This is most likely a bug in the mesa state tracker, but do the
>>>>> quick
>>>>> hack for now to avoid the divide by 0.
>>>> This is not a bug: stride 0 means that the vertex attribute is
>>>> constant for all vertices.
>>> Right, it's how our vbo code handles cases like
>>> glBegin(primitive);
>>> glColor4f(...);
>>> glVertex(...);
>>> glVertex(...);
>>> glVertex(...);
>>> glEnd();
>>>
>>>> Thus, the patch is not likely to be correct: you should instead
>>>> either
>>>> program stride 0 to the hardware if supported, or fetch the vertex
>>>> attribute with the CPU
>>> Dave, jfyi, i implemented this a long time ago in svga, just search
>>> for
>>> zero_stride in there (svga_hw_update_zero_stride in particular), you
>>> should be
>>> able to almost simply copy&paste that code.
>>>
>>> z
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


More information about the mesa-dev mailing list