On Mon, 2010-04-12 at 07:56 -0700, Alex Deucher wrote:
> On Mon, Apr 12, 2010 at 10:17 AM, Roland Scheidegger
> 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
On Mon, Apr 12, 2010 at 10:17 AM, Roland Scheidegger 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 div
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 so
On Sun, Apr 11, 2010 at 6:38 PM, Keith Whitwell
wrote:
> On Sun, Apr 11, 2010 at 9:33 AM, Luca Barbieri wrote:
>> Why?
>>
>> At least all nVidia cards directly support this, and it allows code like
>> this:
>>
>> hw_set_vertex_attrib(idx, v)
>> {
>> write command to set vertex attrib on GPU f
On Sun, Apr 11, 2010 at 9:33 AM, Luca Barbieri wrote:
> Why?
>
> At least all nVidia cards directly support this, and it allows code like this:
>
> hw_set_vertex_attrib(idx, v)
> {
> write command to set vertex attrib on GPU fifo
> write idx on GPU fifo
> write v on GPU fifo
> return;
On 11.04.2010 09:32, Luca Barbieri 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)
>>
> Wouldn't that require changing and recompiling the vertex shaders,
> r
Why?
At least all nVidia cards directly support this, and it allows code like this:
hw_set_vertex_attrib(idx, v)
{
write command to set vertex attrib on GPU fifo
write idx on GPU fifo
write v on GPU fifo
return;
}
glColor()
{
pipe->set_vertex_attrib(COLOR, v);
return;
}
On Sun, Apr 11, 2010 at 9:32 AM, Luca Barbieri wrote:
> IMHO what could be done is to add an explicit API for that instead
> ("set_vertex_attrib") and have a special vertex buffer index in the
> vertex element state that means "I'll call set_vertex_attrib for this
> element".
>
> As an additional
> 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)
Wouldn't that require changing and recompiling the vertex shaders,
reading the constants from the driver anyway, or just bind
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 wrote:
On Saturday 10 April 2010 18
On Saturday 10 April 2010 22:43:40 Dave Airlie wrote:
> On Sun, Apr 11, 2010 at 9:27 AM, Zack Rusin wrote:
Small typo:
> > glColor4f(...);
> > glBegin(primitive);
> > glVertex(...);
> > glVertex(...);
> > glVertex(...);
> > glEnd();
> >
> >> Thus, the patch is not likely to be correct: you shoul
On Sun, Apr 11, 2010 at 9:27 AM, Zack Rusin 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
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
>
13 matches
Mail list logo
