12:38 dboyan: hakzsam: I know why AMD_perfmon in nouveau are all returning ints
12:39 dboyan: hakzsam: smXY_hw_metric_calc_result casts floating point values to uint64_t before filling pipe_query_result
12:40 hakzsam: yeah, for performance metrics, but for performance counters you should see floats
12:42 dboyan: you mean nvc0_query_hw_sm.c?
12:42 hakzsam: yes (performance queries)
12:45 dboyan: Really? https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c#n2701
12:46 hakzsam: ah right, I thought it was float
12:47 dboyan: Also https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c#n701
12:47 hakzsam: I think the easier way is to multiply by 100 and return integers when the float value is [0.0,1.0]
12:47 dboyan: MP counters seems to be all ints, but there are several metrics that are percentages or floats
12:48 hakzsam: right
12:48 dboyan: Can't we use the union in pipe_query_result?
12:48 hakzsam: the HUD doesn't really support floats, IIRC you are likely going to break it
12:49 hakzsam: radeonsi never return floats, nouveau might want to do something similar
12:50 dboyan: I haven't seen how HUD is handling this, but st_GetPerfMonitorResult seems to handling it correctly
12:50 hakzsam: yes, it should work for amd_perfmon
12:51 dboyan: btw, lack of float support is really bad for metrics like ipc
12:51 hakzsam: I don't remember all the details about the HUD and floats to be honest, but when I tried it was a fail :)
12:51 hakzsam: well, multiply by something, issued fixed?
12:53 dboyan: The problem lies within wrong interpretation. Some percent based metrics have type float in AMD_perfmon. They returns int in nouveau but are interpreted as float outside
12:55 hakzsam: this has never been a problem for me, but I can understand your frustration
12:55 dboyan: so the current code breaks AMD_perfmon
12:55 hakzsam: if I have time later today, I will plug back a card and double check
12:56 dboyan: thanks, I'll check the hud part and try to figure that out
12:57 hakzsam: do you have a particular metric that doesn't work like it should? ipc?
12:58 dboyan: The most serious one is ipc. I actually can reinterpret percentage as ints for others
12:59 hakzsam: okay
13:00 hakzsam: do you have a maxwell btw?
13:04 dboyan: I have an gtx 960, but I currently don't have a nouveau setup there
13:04 dboyan: yeah, HUD doesn't seem to support floating point values
13:05 hakzsam: you might be interested by inst_issued0
13:06 hakzsam: it returns the number of cycles when the hw doesn't issue any instructions
13:06 hakzsam: it was very useful for maxwell sched codes and it might be useful for your project
13:06 dboyan: does it work on pascal by any chance?
13:08 hakzsam: I haven't tested pascal with nouveau, can't say
13:08 hakzsam: but I would say no
13:08 hakzsam: sadly, perf counters usually change between generations
13:09 dboyan: yeah, at least not properly handled in query functions
13:09 hakzsam: right, and the config is likely wrong
13:29 dboyan: hakzsam: Do we want to properly handle pascal in performance query, at least returning empty metric and counter list before figuring that out?
13:30 hakzsam: I would prefer to have full support in one shot
13:30 dboyan: Hopefully it doesn't differ too much from maxwell, since isa is basically the same
13:31 hakzsam: unrelated :) look at fermi perf counters
13:31 hakzsam: they are many variants
13:31 hakzsam: if we are lucky then yeah, should be quite similar
13:32 hakzsam: but I don't think we are going to :)
13:57 libreuser: hi
13:59 libreuser: i run GNU Parabola (similar to Arch) and I have blinking problem when play video.
14:01 libreuser: ^ NVIDIA card geforce 680 OC [GK104]geforce 680 OC [GK104]
14:32 karolherbst: libreuser: what kind of blinking?
15:05 RSpliet: mupuf: RE not dropping older GPU drivers
15:05 mupuf: ?
15:05 RSpliet: there is something to say for not building them by default if they are known broken rather than completely removing them from the tree...
15:06 mupuf: nope, I meant they need to be fixed and left alone, so as we don't need to do QA on them all the time
15:06 RSpliet: although I encourage any talented unemployed developer to come and sink some time in our legacy code :-D
15:06 RSpliet: (it's hard to find a mix of talented and unemployed, isn't it?)
15:07 karolherbst: mupuf: yes
15:07 karolherbst: mupuf: exactly this
15:07 karolherbst: fix abstraction layers if abstraction layers break things
15:07 karolherbst: and change them in a way, so that nothing breaks ;)
15:08 RSpliet: mupuf: I feel though that most problems aren't new bugs caused in mesa abstractions, but rather software picking up op features that touch untested codepaths
15:08 RSpliet: (DMs, display "servers" ;-))
15:09 karolherbst: most important reason: mesa links against openssl
15:09 karolherbst: openssl ABI breaks sometimes
15:09 karolherbst: tell the user not to use recent openssl cause their GPU is old: funny and stupid
15:10 RSpliet: karolherbst: that's not what I meant at least. My point in case is breaking of pidgin emoticon rendering since switching to Wayland (on Fermi mind you!)
15:11 RSpliet: we've started using different code paths, user perceives a regression. Nothing in Mesa changed though
15:11 mupuf: RSpliet: ah, fair point
15:11 mupuf: we just can't avoid testing, can we? :D
15:11 RSpliet: Nope!
15:11 mupuf: well, working on it ;)
15:12 mupuf: I am unit testing my testing system now
15:12 RSpliet: mupuf: are you wearing a cape? 'cos you sure as hell are a hery
15:12 RSpliet: *hero
15:12 mupuf: so, coming close!
15:12 mupuf: coming soon*
15:12 mupuf: Super pufmu!
15:13 mupuf: https://scontent-lhr3-1.xx.fbcdn.net/v/t1.0-9/63644_1637054081000_2010958_n.jpg?oh=1f770e9f78e952b5c07566f89c7a1df3&oe=59AF8DFA
15:14 mupuf: this was made by a previous flatmate, after I helped him with something :D