<div dir="ltr">The Gallium state tracker has a st_viewport that it puts into driver->Viewport function table.<div><br></div><div>It's not clear to me how _NEW_VIEWPORT replaces the function of the Driver->Viewport call.</div>
<div><br></div><div>Is it really safe to remove the driver->Viewport call for Gallium?</div><div><br></div><div>Courtney</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 12:31 PM, Brian Paul <span dir="ltr"><<a href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 11/04/2013 11:43 AM, Ian Romanick wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
On 11/01/2013 04:12 PM, Francisco Jerez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ian Romanick <<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>> writes:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11/01/2013 02:04 PM, Courtney Goeltzenleuchter wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[...]<br>
</blockquote>
More often, the dd_function_table functions allow core Mesa to<br>
signal the driver driver that something happened... and the<br>
driver may need to do something in response. For DRI2 drivers,<br>
the Viewport function is a good example. DRI2 drivers use that<br>
signal as a hint that the window may have been resized.<br>
<br>
Other dd_function_table functions are used by core Mesa to<br>
request the driver create or destroy some resource (e.g., texture<br>
storage).<br>
<br>
If it weren't for the way nouveau used the DepthRange and Scissor<br>
hooks, I think we could just about get rid of them altogether. I<br>
wish that driver just used the dirty state bits like everyone<br>
else. :(<br>
</blockquote>
<br>
Cases like the new dd_function_table::Scissor and ::Viewport hooks<br>
introduced in this patch series are the reason why nouveau tends<br>
to prefer overriding the dd_function_table to keep track of state<br>
changes rather than looking at the ctx->NewState bits, because the<br>
latter tend to be very coarse-grained -- e.g. there's one big<br>
_NEW_TEXTURE flag for all the state of all texture units while<br>
nouveau is able to update a subset of the texture state<br>
independently for only those texture units that have changed.<br>
<br>
With the dd_function_table interface proposed in this patch series<br>
it would be possible for the drivers to update the state of each<br>
viewport in the viewport array independently, which might be<br>
beneficial for some hardware someday, removing ::DepthRange and<br>
::Scissor would preclude that possibility.<br>
</blockquote>
<br>
Right... I wonder if we might be better of just tracking a bit per<br>
viewport in the gl_context. I'm assuming we'll end up with something<br>
like:<br>
<br>
struct gl_viewport_attrib Viewports[MAX_VIEWPORTS];<br>
<br>
in the gl_context. It would be easy to add<br>
<br>
GLbitfield _DirtyViewports;<br>
<br>
along side it. The various Viewport and DepthRange functions would<br>
set bits in that field along with _NEW_VIEWPORT. Drivers that care<br>
could examine (and clear) those bits.<br>
<br>
We'd do similar for Scissor.<br>
<br>
Looking at the i965 hardware (and our driver architecture), I believe<br>
we have to upload all of the viewports anytime there's a change<br>
anyway. The viewports are just stored as an array in a BO. See<br>
gen7_upload_sf_clip_viewport and similar functions.<br>
<br>
Marek: Do you know what Radeon / Gallium want?<br>
</blockquote>
<br></div></div>
The gallium interface takes a start,count array of viewports. The st/mesa state tracker could use the bitfield to determine the changed range. But we also have the CSO module to help filter out redundant state changes.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Brian</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Courtney Goeltzenleuchter<br><div>LunarG</div><div><img src="http://media.lunarg.com/wp-content/themes/LunarG/images/logo.png" width="96" height="65"><br>
</div></div>
</div>