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