rubbish shader removed by Catalyst?

991060

Regular
A friend of mine wrote a fillrate test program, I did some primitive test with it.

program #1
ps_2_0

dcl t0
mov r0, t0
mov r1, t0
mov r2, t0
mov r3, t0
mov r5, t0

mul r0, r0, c0 // pass1
mul r1, r1, c1 // pass1

mul r2, r2, c2 // pass2
mul r3, r3, c3 // pass2

add r0, r0, r1 // pass3
add r2, r2, r3 // pass3

add r0, r2, r0 // pass4

mov oC0, r0

program #2
ps_2_0

dcl t0
mov r0, t0
mov r1, t0
mov r2, t0
mov r3, t0
mov r5, t0

mul r0, r0, c0 // pass1
mul r1, r1, c1 // pass1

mul r2, r2, c2 // pass2
mul r3, r3, c3 // pass2

add r0, r0, r1 // pass3
add r2, r2, r3 // pass3

add r0, r2, r0 // pass4

mov oC0, r5

I got 525 MP/s with program #1 and 2476 MP/S with program #2, which suggests that current Catalyst(3.9) can effectly remove those instructions which don't contribute to the final result.
 
I'd !$%"-ing well hope so. The first program calculates 4 * t0^2, the second is a copy.

Of course the second one runs faster. It'd be a pretty shoddy compiler that didn't spot that!
 
Re: rubbish shader filtering on Catalyst?

991060 said:
I got 525 MP/s with program #1 and 2476 MP/S with program #2, which suggests that current Catalyst(3.9) can effectly remove those instructions which don't contribute to the final result.

And this is a bad thing :oops: :?:
 
Re: rubbish shader filtering on Catalyst?

991060 said:
which suggests that current Catalyst(3.9) can effectly remove those instructions which don't contribute to the final result.
DX shader instructions/registers/whatever don't necessarily match actual hardware instructions/registers. The driver always does a conversion D3D->MyOwnShader, it can do whatever it wants as long as the resulting shader does the same job.
Actually, it's good that it does dead-code removal (HLSL probably would also do it, if you'd compile equivalent shader). It can also remove unused texture reads; put instructions into separate pipes (the case with R3x0), etc etc.
 
Re: rubbish shader filtering on Catalyst?

nelg said:
And this is a bad thing :oops: :?:

I think you read the headline wrong, he means "filter is removing rubbish shader code" not that the filter is rubbish.

I pretty am sure that 991060 thinks this is a good thing.
 
Re: rubbish shader filtering on Catalyst?

Tim said:
nelg said:
And this is a bad thing :oops: :?:

I think you read the headline wrong, he means "filter is removing rubbish shader code" not that the filter is rubbish.

I pretty am sure that 991060 thinks this is a good thing.

i think it can be read both ways
 
Re: rubbish shader filtering on Catalyst?

Tim said:
nelg said:
And this is a bad thing :oops: :?:

I think you read the headline wrong, he means "filter is removing rubbish shader code" not that the filter is rubbish.

I pretty am sure that 991060 thinks this is a good thing.

If so I am sorry I read it hat way. :)
 
sorry about the "rubbish" title, I hope some day B3D apply a filter to make it more readable :LOL: .

NV31 scored 98 MP/S with program#1 and 732 MP/S with program#2.

obviously,these rubbish shaders are very easy to detect and driver teams from both companies did a good job at removing them.

edit: I filtered the title by myself, there should be no multivocals now. :oops:
 
PSarge said:
I'd !$%"-ing well hope so. The first program calculates 4 * t0^2, the second is a copy.

Of course the second one runs faster. It'd be a pretty shoddy compiler that didn't spot that!
OTOH, good compilers are able to give you warnings on such optimizations and also permit to turn em off.
 
no_way said:
OTOH, good compilers are able to give you warnings on such optimizations and also permit to turn em off.
Why do you want a warning or a switch? Sure if there's a size/speed trade off it's nice if you can say which is more important to you, but in the case of short circuiting redundant code there is no disadvantage to doing the optimisation.
Of course, having an arm reach out of the monitor and slap you round the face for writing stupid code.... That could be useful! :p

(penny drops) Ahh, maybe that's the purpose of the warning.
 
no_way said:
OTOH, good compilers are able to give you warnings on such optimizations and also permit to turn em off.
Depends how you define 'optimisation'. There will be some class of 'optimisations' that are inherent to the compile process.

I'm not three keen on the idea of handing optimisation control off to the application in a case where so much else about the process is implementation-defined. I want 'it just works'; I don't want 'Hey, I can flip this switch and for nebulous gain, slow the hardware down 50%' <cough>using 32 bit textures for ones that look fine compressed<cough>.
 
Even the few shaders which I have developed don't contain trashy code in them.
I use RenderMonkey. :D

If I ever should develop trashy code in general, I would hope someone takes the crack pipe out of my mouth and gives me a good smack up the ass.
 
no_way said:
OTOH, good compilers are able to give you warnings on such optimizations and also permit to turn em off.

No good compilers exist then. All compilers have some safe optimizations even with the most conservative settings.
 
Tim said:
No good compilers exist then. All compilers have some safe optimizations even with the most conservative settings.

Hm ? ALL compilers ? Thats quite big news to me. Especially when considering assembly languages. Because if this were true, quite many bits of the code that i have written would simply cease to work, particularly some that rely on precise instruction timings or exact code size. Atmel, Microchip and Zilog should be very worried.
I think even my Visual C debugging tools would get pretty confused.
 
Back
Top