various cffdump improvements for multi-draw indirect #21
Conversation
Add the ability to tell rnndec to add a variant when parsing a bitfield with enum type. This will be useful for "opcode" type fields that change the meaning of the rest of the packet, particularly CP_DRAW_INDIRECT_MULTI.
This should let us significantly clean up adreno_pm4.xml.
It shouldn't be necessary to have _HI and _LO fields just for cffdump.
|
Looks nice.. although I suppose it depends on parsing the packet in-order, which won't (currently) be the case for the lua scripting API. Possibly if we are not using the "dynamic variant" feature with any packet that any of the lua scripts look at, it is ok for the short term. It is making me think that I should setup some sort of CI for cffdump/etc. Not sure how different github CI is from gitlab, maybe this is a good excuse to move this tree to gitlab. |
Well, I'm not sure how the lua scripting stuff works, but you kind of have to read the packet in-order in order to decode it properly... so you'll have to make sure that happens anyway if you want to try to parse |
The current approach of marking up
CP_DRAW_INDIRECT_MULTIisn't going to work with the indirect count variants. Theaddvariantsmagic lets us make the opcode a variant we can match on, with no cffdump-specific code. While here, I also added some things that should make it easier to create less verbose packet definitions, that I'll take advantage of in the Mesa MR.