Want F-Buffer?

[Xmas]

It would be no problem for ATI to report more than 96 Instructions through D3DCAPS9.PS20Caps.MaxPixelShaderInstructionSlots.
And they could probably set D3DPS20CAPS_NODEPENDENTREADLIMIT and D3DPS20CAPS_NOTEXINSTRUCTIONLIMIT, maybe Arbitrary Swizzle, too.
Because each of the nine PS2.x "Extensions" is optional and independent from the others.
Saying PS2.0 has a maximum of 96 instructions is a bit misleading, because being able to handle 97 instructions already makes the implementation PS2.x

 

[Xmas]

SO please spare Mr. Huddy's mailbox unless YOU are developing a game which would benefit from huge (say 1000-2000) shaders.

I think a shader with 150 arithmetic instructions is equally fitting. And why would it have to be a game?

 

[Ilfirin]

It would be no problem for ATI to report more than 96 Instructions through D3DCAPS9.PS20Caps.MaxPixelShaderInstructionSlots.
And they could probably set D3DPS20CAPS_NODEPENDENTREADLIMIT and D3DPS20CAPS_NOTEXINSTRUCTIONLIMIT, maybe Arbitrary Swizzle, too.
Because each of the nine PS2.x "Extensions" is optional and independent from the others.

Ok, I wasn't aware that all the additional capabilities were optional. So 512 of the instructions could be supported without problems, that's pretty good. Am I right to think that the same optionality can't be extended to PS3.0 though, since the documentation drops the 'if this caps bit is set' wording, and simply states, for example, "There are no dependent read limits"?

But this brings up another question - what actually constitutes an instruction slot? If there was a piece of PS2.0 hardware with an F-Buffer, it would still only have 96 instruction slots, it just also has the ability to flush those to memory and re-use those instruction slots to execute shaders of any length. So would it be more correct to modify 'MaxPShaderInstructionsExecuted' rather than 'D3DCAPS9.PS20Caps.MaxPixelShaderInstructionSlots'?

But the former was intended for looping and such, not for this, so I don't know. I think it's pretty clear that MS didn't expect something like this when they wrote the DX9 spec.

[edit] Whoops, forgot the order I put 'MaxPShder...' and "D3DCAPS9.PS20Caps.MaxPixel...'

 

[MDolenc]

Ok, I wasn't aware that all the additional capabilities were optional. So 512 of the instructions could be supported without problems, that's pretty good. Am I right to think that the same optionality can't be extended to PS3.0 though, since the documentation drops the 'if this caps bit is set' wording, and simply states, for example, "There are no dependent read limits"?

In ps_3_0 only instruction slot count is optional. You have to support everything from gradient instructions (ddx/ddy) to full dynamic branching plus some other things not present in ps_2_x.

But this brings up another question - what actually constitutes an instruction slot? If there was a piece of PS2.0 hardware with an F-Buffer, it would still only have 96 instruction slots, it just also has the ability to flush those to memory and re-use those instruction slots to execute shaders of any length. So would it be more correct to modify 'MaxPShaderInstructionsExecuted' rather than 'D3DCAPS9.PS20Caps.MaxPixelShaderInstructionSlots'?

But the latter was intended for looping and such, not for this, so I don't know. I think it's pretty clear that MS didn't expect something like this when they wrote the DX9 spec.

Yes MaxPShaderInstructionsExecuted is intended for looping. They could however expose unlimited instruction slots via ps_2_sw (ps 2.0 software). If DX runtime lets this through that is...

 

[Xmas]

But this brings up another question - what actually constitutes an instruction slot? If there was a piece of PS2.0 hardware with an F-Buffer, it would still only have 96 instruction slots, it just also has the ability to flush those to memory and re-use those instruction slots to execute shaders of any length. So would it be more correct to modify 'MaxPShaderInstructionsExecuted' rather than 'D3DCAPS9.PS20Caps.MaxPixelShaderInstructionSlots'?

No, it wouldn't. How the hardware handles those instructions doesn't matter for the software, so the number should be exposed through MaxPixelShaderInstructionSlots. 'Instruction slot' is used because some instructions may be macro instructions that expand to several ops. So they take more than one instruction slot.

 

[Ilfirin]

Right, but an instruction slot and an instruction (note that when I say instruction, I mean a raw instruction, not a macro) are two different things (that just happen to be the same right now). My question was what definition of an instruction slot do they mean with that caps bit - a raw instruction, or the number of slots in the hardware for holding instructions? As it stands right now the hardware (note also that here I am assuming a hypothetical piece of hardware whose hardware details exactly equal that of the DX9 spec) can execute 96 instructions, and it also has 96 instruction slots but with an F-buffer those two items are no longer the same. The number of instructions the card can execute can be infinity, but the number of instruction slots can be as low as 96 (or even lower), or a lot higher, so which does the caps bit refer to?

 

[Simon F]

Ilfirin,
I don't know all the details, but from what's been said, I don't see that the F-buffer model fits into either category - unless you have, say, a large program whose loops that can be trivially unwound into a big linear sequence.

 

[Ilfirin]

Simon F,
That's kinda the point I'm trying to make - it doesn't really fit into any of DX's shading categories or caps bits. But I believe it really should. Surely a technique like this (F-Buffer) must have entered into the minds of the people putting together the DX spec? It's not that big of a problem right now, but I suspect it will be as more and more hardware start implementing similar techniques. Either the DX spec needs revising, or the interpretations of what the DX spec says do.

As far as literal interpretations go, I would say that leaving the instruction slot cap bit as an indication of how many instruction slots (and thus a very loose indication of pixel shading speed) the hardware has, and revising the interpretation of 'instructions executed' (from just loops to a more general case) would make the most sense. Harumph, maybe we should ask MS's DX department.

 

[Simon F]

Simon F,
That's kinda the point I'm trying to make - it doesn't really fit into any of DX's shading categories or caps bits. But I believe it really should. Surely a technique like this (F-Buffer) must have entered into the minds of the people putting together the DX spec?

Hmmm. Perhaps it has. I'm not really up to speed with Pixel Shader details, but maybe you could do something similar using MRTs?

 

[Xmas]

Right, but an instruction slot and an instruction (note that when I say instruction, I mean a raw instruction, not a macro) are two different things (that just happen to be the same right now). My question was what definition of an instruction slot do they mean with that caps bit - a raw instruction, or the number of slots in the hardware for holding instructions? As it stands right now the hardware (note also that here I am assuming a hypothetical piece of hardware whose hardware details exactly equal that of the DX9 spec) can execute 96 instructions, and it also has 96 instruction slots but with an F-buffer those two items are no longer the same. The number of instructions the card can execute can be infinity, but the number of instruction slots can be as low as 96 (or even lower), or a lot higher, so which does the caps bit refer to?

I don't think the F-Buffer should be in any way visible to the software, so the number of instruction slots should be 512 (the maximum for PS2.x). It's not relevant how this instruction count is achieved internally.
The number of instruction slots is just an indication whether an implementation can execute a given shader.