On Wednesday, December 12, 2018 9:09:54 AM PST Jason Ekstrand 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+? > > --Jason
That's a good point. It's not great either way, but... Adjusting the MOCS fields in the XML by 1-bit could be confusing when reading the XML. But, the decoder would see the correct index, rather than 2x the index. So, that does seem better? I'll probably go with this for now but I'd be happy to shift things by a bit and fix the numeric values to be real indices on Gen9+. --Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
