Rune Petersen wrote: > 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 >>>> result.position. >>>> >>>> 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 ? >> > > Now I remember why I can't use radeon->dri.drawable, at least not > directly when the shader code is added: > > When the window size changes the constants have to be updated. > > Is there a way for the driver to update a constant after construction? >
This is an age-old dilemma... The i965 driver gets around this by locking the hardware before validating and emitting state and drawing commands and unlocking again afterwards - so the window can't change size in the meantime. Other drivers tend to just deal with the occasional incorrectness. In general this is something we need to get a bit better at. API's like DX9 and GL/ES do away with frontbuffer rendering which gives the drivers a lot more flexibility in terms of dealing with window moves and resizes, allowing them to pick a time to respond to a resize. With private backbuffers we might get the same benefits at least in the common case. Keith Keith ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
