02:16mwk: *sigh* and that was the area I initially considered least scary
06:17jcapik: Hello everyone
06:18jcapik: Searching for help with a buggy decoding using vdpau+nouveau
06:19jcapik: don't wanna switch to proprietary drivers just because of that
06:19jcapik: orbea: hi, yup
06:19orbea: so buggy as in graphical glitches?
06:19orbea: its a well known issue...unfortunately
06:20orbea: apparently hard to solve too
06:20jcapik: some scenes (like blue fog) contain squares of wrong colors
06:20orbea: I switch to mpv with software decoding for those...
06:20orbea: I would not try hardware decoding with mpv + nouveau though
06:21jcapik: well ... I can disable vdpau or just the ffh264 codec for vdpau
06:21orbea: its bad and the mpv dev would rather give users shit over using nouveau than fixing it
06:21jcapik: but in that case it eats CPU
06:22jcapik: I simply want it to work .....
06:22jcapik: if it is a known issue
06:22jcapik: and nobody knows how to fix it, then I'll have to switch back to proprietary
06:23orbea: i'd rather use software decoding myself
06:23orbea: not all videos do it at least...
06:24jcapik: well .... but you need to know which ones ....
06:24jcapik: and it is annoying when you invite someone for a movie and then ..... surprise!
06:24orbea: by trying them and finding out. ANimated stuff does it a lot more for me than live action.
06:27orbea: how the files were made is probably related. for exmaple some shows will never do it, while others do it badly.
06:27jcapik: VLC suffers the same problems
06:28jcapik: so, it is not player related
06:28orbea: mplayer generally is the best for hardware decoding with nouveau I htink
06:28jcapik: the firmware is extracted from the proprietary driver, so .... we can exclude it
06:29orbea: but yea, I would love to see it fixed too, eventually :)
06:30jcapik: do you know who wrote the support?
06:31orbea: not sure, one of the actual devs here probably knows more on that
09:59mwk: well, I give up
09:59mwk: NV10 PIPE state is literally impossible to read
10:01mwk: the act of reading PIPE 0x4470 overwrites PIPE 0x810 with data from 0x4470; but reading PIPE 0x810 overwrites PIPE 0x4470 with the value 0x810
10:03mwk: it seems the nvidia driver knows it and specifically reads 0x4470 first if there's a Celsius object on the channel (which doesn't need 0x810), or 0x810 first if there's a D3D object on the channel (which has no use for 0x4470 value)
10:05mwk: I guess from now on, I'll call these two cells "position" and "momentum", respectively...
10:09mwk: I suppose I'll do a coin toss on every test to decide which one to check on that run and ignore the other...
13:11funfunctor: does anyone here have some useful python scripts for dealing with iommtrace outputs?
13:23pmoreau: funfunctor: There is demmio in envytools, but it is a C program
13:31funfunctor: pmoreau: thats fine, how does it work?
13:31funfunctor: here? https://github.com/envytools/envytools
13:32pmoreau: I haven’t looked at how it works, just used it to convert my MMIOtraces into something readable
13:33funfunctor: hmm looks highly nv specific ok
13:33funfunctor: fair enough
13:33funfunctor: I am RE a blackmagic design card
13:33pmoreau: i.e. replace the addresses by readable names (if known) and, if possible, split values into the known fields
13:35pmoreau: Sounds fun!
13:36pmoreau: (I didn't know Blackmagic Design was a company, so I was a bit confused as to what a blackmagic design card could be)
13:39funfunctor: pmoreau: yea there driver is two parts, crappy shim for Linux support and the main hw support in the form of a C++ library
13:39funfunctor: because C++ is heap based its really hard to see how that works so I figure its easier to trace
13:40funfunctor: I have no idea about register names
13:48funfunctor: pmoreau: any suggestions on how to extract possibly register names if I: a.) know the offset (from the trace) and b.) have the drivers C++ library which has debug symbols
13:57pmoreau: Hum… no idea, sorry
15:45imirkin: funfunctor: the idea is that you have a database of registers sitting in xml files that rnn can parse, and demmio has the logic of figuring out which writes go to which register addresses (i.e. which write goes to which bar, which bar does what, etc)
15:46imirkin: funfunctor: as for populating that file for your hw, you're on your own.
15:47funfunctor: imirkin the hw only has the one BAR
15:47funfunctor: I dont think it has that much complexity
15:47funfunctor: well working out the registers *is* my very task
15:49funfunctor: imirkin I wrote this => https://paste.fedoraproject.org/514751/14830265/
15:49funfunctor: any suggestions?
15:51imirkin: suggestions on how to do RE? mwk is the jedi master of RE...
15:51funfunctor: nar just my script
15:51imirkin: i can really only say the obvious... try to single out simple actions by the driver and make the driver repeat them a bunch. then look at what changes in the trace
15:52funfunctor: ok what timezone is he/she online?
15:52imirkin: and infer meanings of registers based on the values you were getting the driver to use
15:52funfunctor: imirkin yea exercise paths, right now I am just looking at modprobing the thing and working out something else simple
15:52imirkin: mmm... i think mwk is in UTC+2, but he doesn't exactly keep 9-5 hours :)
15:52funfunctor: haha ;)
15:52imirkin: probably more like 5-9. heh.
15:52funfunctor: 3am here
15:53funfunctor: really only just looking to for tips on organizing the trace results a bit
15:54imirkin: yeah dunno. i've never done anything like that from scratch.
15:54funfunctor: the above takes the trace and creates a struct with members at each offset written to or read from and the number of btis wide needed
15:55funfunctor: the whole thing is u16 wide so it looks like the one register in truth
15:56funfunctor: wait no nvm
15:56funfunctor: gezz need sleep..
15:57funfunctor: alright any way, thanks and night night
21:29pmoreau: Finally back! I had forgotten I also needed to update the SSL certificate for my IRC bouncer… so my client was refusing to connect as it had expired