<lynxeye>
austriancoder: (And anyone else with a opinion on this) I was wondering about the code style in the etnaviv Mesa driver for a while. There are still a lot of places where variable declarations happen in the middle of a block, not at the top. While this is totally legal in C99 my personal opinion is that it makes some functions hard to read. Is it just me, or should we try to avoid this style and correct it over time?
<lynxeye>
Not sure if I'm just primed by working on lots of kernel code where this style isn't allowed.
pcercuei has joined #etnaviv
mvlad has joined #etnaviv
mvlad has quit [Ping timeout: 480 seconds]
mvlad has joined #etnaviv
<lynxeye>
marex: Any way I could bribe you to get the multithreading rework a test?
<austriancoder>
lynxeye: I stepped up to test it.. but the last weeks my day job eat all my time and motivation. The situation changes as the workload at my day job is back to normal now. I try to run the test soon .. I promise.
<austriancoder>
lynxeye: reagring the code style .. give me some time to think about it. In the end I think we should also move to clang-format to get a unique code style (like freedreno did)
<lynxeye>
austriancoder: Thanks, I would appreciate that. I don't really dare to merge this without being able to properly reproduce the issues myself.
ad__ has quit []
ad__ has joined #etnaviv
ad__ has quit []
ad__ has joined #etnaviv
ad__ has quit []
ad__ has joined #etnaviv
<tomeu>
what should I pass to --struct-file= in dump_cmdstream.py ?
<austriancoder>
tomeu: i am not in front of any pc .. but the JSON file from data/ .. but it should work automatically as the fdr stores the used gal version
<tomeu>
nice, got something
<tomeu>
guess gcvHAL_QUERY_CHIP_IDENTITY is normally the first command?
<tomeu>
and .hardwareType = gcvHARDWARE_INVALID, probably means that the struct has changed