Bug 5366

This ties into the work IDR's student group are doing on vertex program
optimization.

It seems like this might be an R300-specific slowdown, as other architectures
cope fine with a vertex program that produces results that are subsequently
ignored by the fragment program.

Out of interest, if you modify the fragment program to read the computed color
value, does performance improve?

(In reply to comment #1)
> It seems like this might be an R300-specific slowdown, as other architectures
> cope fine with a vertex program that produces results that are subsequently
> ignored by the fragment program.
> 
> Out of interest, if you modify the fragment program to read the computed color
> value, does performance improve?

Yes, as long as it gets read.

It's been quite a while since I looked at r300, but I suspect that the routing
of data between vtx and frag programs still isn't quite right.

Do you also see a speedup if you modify r300_state.c::r300_setup_rs_unit to
route col0 into a fragment program register, even if it isn't read?

You'll also have to modify r300_fragprog.c::init_program to assume that col0
exists so that the fragment program reads the correct registers.

(In reply to comment #3)
> It's been quite a while since I looked at r300, but I suspect that the routing
> of data between vtx and frag programs still isn't quite right.
> 
> Do you also see a speedup if you modify r300_state.c::r300_setup_rs_unit to
> route col0 into a fragment program register, even if it isn't read?
> 
> You'll also have to modify r300_fragprog.c::init_program to assume that col0
> exists so that the fragment program reads the correct registers.

I cannot really do that. R300_RS_ROUTE_0_COLOR is actually vp result register
number. Although this starts at zero, its assigned at vof(R300_RS_ROUTE_0_COLOR).

AFAIK, passing undefined values to interpolators is also illegal and will lock
the GPU.

(In reply to comment #4)
> I cannot really do that. R300_RS_ROUTE_0_COLOR is actually vp result register
> number. Although this starts at zero, its assigned at vof(R300_RS_ROUTE_0_COLOR).
> 
> AFAIK, passing undefined values to interpolators is also illegal and will lock
> the GPU.

Yes, I believe this is the case.  But I don't see how the data is undefined, you
mention that the vp writes the value.

Currently, the rs unit setup will just throw away col0 if the fp doesn't want
it.  I'm suggesting that you make it pass the value to the fp register anyway
(which it'll just ignore).  I can't recall any lockups from not using a value in
a fragment program.

Perhaps I'm misunderstanding the issue though..

> Currently, the rs unit setup will just throw away col0 if the fp doesn't want
> it.  I'm suggesting that you make it pass the value to the fp register anyway
> (which it'll just ignore).  I can't recall any lockups from not using a value in
> a fragment program.

That seems to fix it as well.

Cool.  I wonder if the entire rs_unit code should be modified to pass all
registers that are written by the vp, regardless of whether they're used or not.

I can't recall how fglrx does this now.

(In reply to comment #7)
> Cool.  I wonder if the entire rs_unit code should be modified to pass all
> registers that are written by the vp, regardless of whether they're used or not.
> 
> I can't recall how fglrx does this now.

Sounds fair enough.

It seems that this only related to colors. arbvptorus.c:138 has similar bogus
instruction too but it doesnt cause problems. Changing it to:
"MOV   result.color.secondary, vertex.texcoord;\n"
brings it back.
However, I vaguely remember that this inst has caused arbvptorus to run at
reduced speed in past.

I can't see this being a problem anymore....

closed