Roland Scheidegger wrote: > Keith Whitwell wrote: >>> 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. > > I think Rune is rather refering to the fact that you can't change (not > with "legal" means at least) the constant you got with > _mesa_add_unnamed_constant.
Ah right. I missed that. > I think there exist at least 2 solutions for that. The clean way would > probably be to add some more INTERNAL_STATE (like i965 driver uses) so > you use _mesa_add_state_reference instead, in this case mesa's shader > code would need to update program parameter based on the drawable > information - I'm not sure if accessing a driver's drawable information > there would get messy). The easier solution would probably be to just > directly manipulate the ParameterValues entry associated with the > constant you added, easy though it might be considered somewhat hackish. > Just don't forget you not only have to update the "constant" within > r300UpdateWindow (if the currently bound fp requires it), but also when > the active fp is switched to another one (and make sure that a parameter > upload is actually triggered if it not already is upon drawable changes). I think the parameter approach is probably the right one. This would require that there be a callback into the driver to get this state, and more importantly, the driver would have to set a bit in ctx->NewState (perhaps _NEW_BUFFERS) to indicate that a statechange has occurred which would affect that internal state atom. 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
