On Wed, Dec 12, 2018 at 11:09 AM Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On Tue, Dec 11, 2018 at 10:31 PM Kenneth Graunke <kenn...@whitecape.org> > wrote: > >> When we first started using genxml, we decided to represent MOCS as an >> actual structure, and pack values. However, in many places, it was more >> convenient to use a numeric value rather than treating it as a struct, >> so we added secondary setters in a bunch of places as well. >> >> We were not entirely consistent, either. Some places only had one. >> Gen6 had both kinds of setters for STATE_BASE_ADDRESS, but newer gens >> only had the struct-based setters. The names were sometimes "Constant >> Buffer Object Control State" instead of "Memory", making it harder to >> find. Many had prefixes like "Vertex Buffer MOCS"...in a vertex buffer >> packet...which is a bit redundant. >> >> On modern hardware, MOCS is simply an index into a table, but we were >> still carrying around the structure with an "Index to MOCS Table" field, >> in addition to the direct numeric setters. This is clunky - we really >> just want a number on new hardware. >> > > 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+? > 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. Note: Neither of those is a NAK. :-)
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
