<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Dec 12, 2018 at 11:09 AM Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 10:31 PM Kenneth Graunke <<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">When we first started using genxml, we decided to represent MOCS as an<br>
actual structure, and pack values.  However, in many places, it was more<br>
convenient to use a numeric value rather than treating it as a struct,<br>
so we added secondary setters in a bunch of places as well.<br>
<br>
We were not entirely consistent, either.  Some places only had one.<br>
Gen6 had both kinds of setters for STATE_BASE_ADDRESS, but newer gens<br>
only had the struct-based setters.  The names were sometimes "Constant<br>
Buffer Object Control State" instead of "Memory", making it harder to<br>
find.  Many had prefixes like "Vertex Buffer MOCS"...in a vertex buffer<br>
packet...which is a bit redundant.<br>
<br>
On modern hardware, MOCS is simply an index into a table, but we were<br>
still carrying around the structure with an "Index to MOCS Table" field,<br>
in addition to the direct numeric setters.  This is clunky - we really<br>
just want a number on new hardware.<br></blockquote><div><br></div><div>This gets a bit sticky because the "Index to MOCS Table" field starts at bit 1 not 0 so the MOCS value in your patch isn't actually the index, it's index * 2.  Do we want to "fix" this and make the MOCS value the thing we actually want on gen9+?</div></div></div></blockquote><div><br></div><div>One other comment:  While the MEMORY_OBJECT_CONTROL_STATE field isn't set by drivers it is decoded by aubinator (though sometimes not correctly :-/) and may be useful to keep around for that reason.</div><div><br></div><div>Note: Neither of those is a NAK. :-)<br></div></div></div>