Keith Whitwell wrote:
> Rune Petersen wrote:
>> Rune Petersen wrote:
>>> Roland Scheidegger wrote:
>>>> Rune Petersen wrote:
>>>>> I hit a problem constructing this:
>>>>> - In order to do range mapping in the vertex shader (if I so choose)
>>>>> I will need a constant (0.5), but how to add it?
>>>> I think this might work similar to what is used for position invariant
>>>> programs, instead of using _mesa_add_state_reference you could try
>>>> _mesa_add_named_parameter. Otherwise, you could always "construct" 0.5
>>>> in the shader itself, since you always have the constants 0 and 1
>>>> available thanks to the powerful swizzling capabilities, though
>>>> surprsingly it seems somewhat complicated. Either use 2 instructions
>>>> (ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of
>>>> these, but I guess the approximated EXP should do (2^-1).
>>> This math in this patch appear sound. the doom3-demo issue appear
>>> unrelated to fragment.position.
>>> This version makes use of existing instructions to calculate
>>> split into 2 parts:
>>> - select_vertex_shader changes
>>> - The actual fragment.position changes
>>> This patch assumes that:
>>> - That the temp used to calculate result.position is safe to use (true
>>> for std. use).
>>> - That fragment.position.x & y wont be used (mostly true, except for
>>> exotic programs.)
>>> In order to fix this, I'll need to know the window size, but how?
> Surely it's right there in radeon->dri.drawable ?
Sure it's is, I just managed to miss it, I'm still new at this =)
It is pretty solid now. position x & y are correct. And no regressions
After some extensive testing, I found that a doom3-demo vertex shader
and the select_vertex_shader code uncovered a bug in the vertex shader.
We can't output result.* unless the fragment shader expects the input.
The fix is to change the unused outputs to an unused temp.