00:21mareko: robclark: can you please fix freedreno for the new mediump instructions f2imp, f2ump, i2fmp, u2fmp: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6283
00:24mareko: robclark: or I'll have to disable fp16 in freedreno
01:11robclark: mareko: I'll try to find some time tomorrow or mon (before the end of the holiday weekend) to have a look, but you can't go pushing fp16 disable to paper over issues, or I will push a revert.. sorry I haven't had as much time recently to follow all the nir MRs but you should have tagged me earlier on it if you need help with the ir3 parts
01:28mareko: robclark: you can always fix it later and reenable fp16 before the next stable branch is made
01:30robclark: it would be a regression
01:30mareko: robclark: in what sense?
01:31robclark: I'll have a look at what we need to add in nir->ir3 in next few days, but you at least need to give me a chance to help, threatening to disable fp16 isn't a great approach ;-)
01:32robclark: sorry, I wasn't aware that some help was needed earlier
01:32mareko: np, that sounds fair
01:44HdkR: robclark: I'm curious what software you're using for tracking performance with ci :)
01:45robclark: unfortunately tracking perf in CI isn't so easy.. it would be great if it was.. but it is a thing I track closely these days
01:46robclark: trust me, I'm pretty tired of watching manhattan get destroyed by robot thing, and car chases ;-)
01:47HdkR: FEX is getting to the point that we need to do CI perf tracking so it would be nice for feedback for what people are using
01:48robclark: anholt has been playing w/ renderdoc replays, but I find that a bit lacking since it reconstructs the entire state each time you replay the same frame... and generally the replay things have a lot of trace replay overhead
01:49robclark: some more automated approach that actually correlated to results seen in real benchmark apps would be super awesome
01:52HdkR: Competitive benchmark comparisons then
01:52robclark: yeah, I wish there were some actually good open src benchmarks that we could enable in CI
01:53robclark: current state isn't anything that could be easily put in CI
01:54HdkR: I still need to find a bunch of applications to slap in to CI for performance testing
01:55robclark: on the android side it is easy, gfxbench is the only thing in the world :-/
01:56robclark: (and also the thing mobile gpu blob driver folks focus on way too much)
01:56kisak: implying there's benchmarks other than glxgears :P
01:57robclark: heh, if glxgears were the benchmark, we could all be retired and sipping umbrella drinks on a beach somewhere ;-)
01:59kisak: oh yeah, it's a brave new world with eglgears_x11
02:00robclark: anyways, these days webgl aquarium is the not-a-benchmark-benchmark :-P
02:00AndrewR: back in time anholt used OpenArena as benchmark, I think .... but it was only ..OpenGL 2 at best?
02:04kisak: HdkR: on a less silly note, phoronix test suite should have oodles of test profiles
02:09AndrewR: kisak, but some of those tests in game area can be x86 binaries + proprietary game data ....
02:11bnieuwenhuizen: robclark: is apitrace better than renderdoc here? IIRC it has a feature to replay a single frame a bunch of times?
02:13robclark: bnieuwenhuizen: mjanes's frameretrace (fork of apitrace) is semi-plausible for benchmarking.. as long as cpu overhead doesn't factor in
02:14robclark: or rather janesma
02:15robclark: renderdoc is useful for debugging rendering issues, but less so for perf
02:16robclark: and the perf cntr capture in frameretrace has been useful a bunch of times.. although I wish it was something I could use against android blob driver for comparision
02:20robclark: I guess the other issue is capturing traces in the first place.. which in android world is hard to do with apitrace
02:55HdkR: kisak: Less about profiles, I more want the infrastructure for handling performance testing for CI with master testing and PR testing :P
02:57HdkR: https://github.com/marketplace/actions/continuous-benchmark I found this which has github integration but I don't know how good it is
02:59HdkR: FEX can't yet run the world, so best to start off with some smaller applications :D
05:32anholt: robclark: I only measure GPU time to try to avoid the replay infrastructure counting. though there's still recompile cost if you don't get to prime it with a frame (an issue for renderdoc, but not our apitraces in traces-db)
05:33anholt: though even recompile cost probably doesn't end up counting
05:34anholt: HdkR: the plan is to do trace replay timing (GPU time only) on our CI boards, and upload data to grafana for tracking regressions.
05:35HdkR: Hm, I've seen grafana around. Is it difficult to interface with?
05:36anholt: I haven't generated queries with it myself, but I've looked at some pretty queries from the fdo transfer dashboard
05:36anholt:heads off to bed, though
05:37HdkR: I'll take a look at it, thanks
08:38ggherdov: Hello, what would be a channel to ask user questions about GPU drivers and Linux?
08:38ggherdov: Eg: "Which i915 commit and Mesa commit added support for the integrated UHD Graphics 620", or "what driver combo do I need to run smoothly on the ComeLake-U Intel mobile CPU/GPU"
10:36mareko: when will piglit CI start working again?
11:01Vanfanel: emersion: This is what I finally do before destroying the KMS buffers and GBM surface: https://github.com/vanfanel/SDL/blob/7906cf5ae9e0132eaa1fa01e879946e80633c72b/src/video/kmsdrm/SDL_kmsdrmvideo.c#L876
11:03Vanfanel: emersion: as you can see, I disconnect the connector from the CRTC, deactivate the CRTC, and set the PRIMARY PLANE CRTC_ID and FB_ID to 0
11:03Vanfanel: emersion: I would like you to take a look and tell me if there's something wrong before I consider this KMSDRM backend for SDL2 definitive, please.
11:04Vanfanel: pq: if you could take a look, I would be very grateful too :)
11:05Vanfanel: I would like to know if what I do is supposed to work with a well-behaving driver
11:06Vanfanel: for somewhat-broken drivers like AMDGPU, I simply point the plane to the TTY buffer as a temporal solution)
11:42Vanfanel: emersion: Lost my connection, in case you answered me...
13:30linusw: Could someone give me a quick ACK on this patch https://firstname.lastname@example.org/T/#u
13:30linusw: So I can unbreak the for-next branch that I screwed up :P
13:50pq: Vanfanel, I would not turn the CRTC off. Instead, leave only the primary plane occupied by an FB that is guaranteed to not have sensitive information and turn all other planes off. Obviously you have to intentionally leak the FB to do that.
13:51pq: doing this will avoid flicker on exit (turning CRTC off and then whoever takes over turns it on again), and might work around the amdgpu bug (which has maybe gone unnoticed since everyone else doesn't turn off the CRTC)
13:54pq: do not try to restore the state there was when you started, but do turn off everything extra you might have used - this should be the nicest way to hand off
13:55pq: whoever takes over next should know to reset everything to their liking, but KMS clients do not tend to reset things they are not going to use like extra planes or gamma tables (hello, fbcon?)
13:57pq: Vanfanel, intentionally leaking the FB requires changes that I understood you're not willing to do, so I suppose what you have is the next best thing.
14:00pq: Vanfanel, if you don't want to leak a GBM buffer, you could create a dumb buffer, clear it with CPU, and put that up, so you can destroy and not leak anything GBM produced. Then just don't RmFB the dumb buffer when you exit.
14:08Vanfanel: pq: when you say leak, do you mean "not destroying it even if it takes up RAM that's never recovered"?
14:51DPA: Regarding the etnaviv device dedublication issue, I've now created this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6610?diff_id=95633&start_sha=dc2e1a9341059af5bd4e086a660cabeb6f87ade5
14:51DPA: I've been testing it with this: https://gitlab.freedesktop.org/-/snippets/1168
14:51DPA: I think it would be good to get some feedback on this.
14:51DPA: There is also something about it that really bothers me, I haven't seen any applications having problems if I just export the wrong handle here, instead of reexporting it for the correct file description:
14:51DPA: Is there a good way to test if I'm doing the right thing here?
15:56robclark: anholt: I suppose I should re-try the renderdoc replay benchmarking now that the thing with gpu getting stuck at like 10MHz for first few frames after resume is fixed.. I suppose that could have been effecting things. And maybe we should try with some multi-frame traces (like 5 frames instead of just one)..
16:40pq: vanf... eh
19:14linusw: Could someone give me a quick ACK on this patch https://email@example.com/T/#u
19:14linusw: So I can unbreak the for-next branch :P
19:46airlied: linusw: ack
19:47linusw: airlied: thx man I merge
19:47sravn: linusw: a-b, but joining lines would have been nice. The new 100 char limits makes for more readable logging
19:47linusw: sravn: thx I'll fix up while applying.
19:47sravn: linusw: Not active at dri-devel these days, day-time job keeps me busy atm.
20:41airlied: chrisf: you know a bit about swiftshader? has it got conformant vs fast paths?
20:53chrisf: airlied, always conformant
20:54airlied: chrisf: no go faster tweaks at all?
20:55chrisf: not to the extent that we produce wrong results
20:55chrisf: up to bugs
20:56airlied: chrisf: llvmpipe has some speedups for texturing that help with compositors etc, but aren't conformant in some corner cases
20:56airlied: currently they are on by default
20:57chrisf: there were a few nasty corners in texturing -- we currently decompress block compressed textures, and replicate cubemap edge texels
20:57airlied: trying to decide how best to address it now that the driver is GL 4.5 conformant in the other paths
20:58airlied: the llvmpipe ones are turning off brilinear, rho calculation accuract, and a quad_lod opt
20:59airlied: and I think there are some sampling fast paths
20:59chrisf: ah -- we definitely gave up some performance with determining lod. old GLES swiftshader took some liberties there but we couldnt pass VK conformance with them
21:00airlied: yeah VK conformance may need another bit of work for llvmpipe as well
21:00chrisf: and robustness hurts
21:00airlied: I should probably just drirc gnome-shell and move on :P
21:00airlied: or provide a build time option
21:01bnieuwenhuizen: airlied: have gnome-shell use explicit lod instructions?
21:01airlied: bnieuwenhuizen: well it's not just gnome-shell
21:01airlied: I think vmware use it in places for the windows aero
21:02bnieuwenhuizen: as alternative for "I should probably just drirc gnome-shell and move on"
21:02airlied: bnieuwenhuizen: well I was going to drirc kwin etc
21:02airlied: all compositors really
21:02airlied: since I think that is the main llvmpipe workload :-P
21:04airlied: I should probably quantify how much affect each opt has on conformance
21:04bnieuwenhuizen: airlied: and on performance :P
21:10airlied: chrisf: do you knkw if you changed line drawing much? lines are one of the last areas of fail for gles32 and vk
21:12chrisf: airlied, very minor tweaks.
21:13chrisf: airlied, only real point of trouble there was in trying to get ANGLE to meet gles2/3 conformance on top of it; EXT_line_rasterization ended up being the best option
21:56airlied: chrisf: ah I'll have to make my core both gles2 and vulkan compliant
22:36rah: I have a problem with mesa's Clover OpenCL implementation:
22:36rah: Invalid bitcast
22:36rah: %16 = bitcast i8* %add.ptr to i8 addrspace(1)*
22:36rah: LLVM ERROR: Broken function found, compilation aborted!
22:38rah: this is not from the compilation log after an errored return from cl::Program::build; this is printed on the console and the program is no longer running
22:45airlied: rah: clover isn't very well supported, but look like a possible clang/llvm bug