This is caused by vp writing col0 but fragprog not reading it. Im leaning torwards solution where dead code removal on vps is issued based on fragprog inputs. This would be done with a hasher similar to what t_vp_build.c and texenvprogram.c have. It would be a lot easier to do this if Mesa would naturally (try) to split vp programs into smaller pieces based on results written. However, I'm not sure its worth implementing...
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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.