03:49 i509vcb: I was wondering if anyone here knows of a way to make vk-deqp dump the raw data in the image_to_image tests
03:50 i509vcb: I have one of the fun issues where one of the tests fails but the data when I view it in the qpa viewer looks just like the reference
06:03 Company: What's the difference between _mesa_is_es3_color_renderable() and is_format_color_renderable() in fbobject.c?
06:03 Company: assuming we're talking about GLES3
06:04 Company: because the first one doesn't check _mesa_has_EXT_color_buffer_half_float() and I wonder if that's deliberate or an oversight
06:05 Company: and yes, I'm writing GTK tests and it loops over formats and encountered RGB16F and tried to glGenerateMipmap() with it
06:08 airlied: EXT_color_buffer_half_float is part of gles3 by any chance?
06:20 Company: airlied: it's defined for GLES 2 but Mesa advertises it as supported with GLES3
06:21 airlied: yeah I just wonder if it just is part of gles3 so not required
06:22 Company: I have no idea how that works
06:24 Company: a8044e87e7cb7284b0f4f582c28de9a4dedd4fa2 says that gles3 adds them all, but apparently RGB16F is an exception
06:25 Company: R, RG, RGBA are added to GLES3 but RGB is not in the 3.2 spec
06:37 airlied: I suspect it is missing something there, though I'm not sure if mipmap generation should be tied to color renderable
06:38 airlied: might be worth filing an issue, tpalli is usually the person who knows that stuff
06:43 Company: let me do that
07:03 Company: it's https://gitlab.freedesktop.org/mesa/mesa/-/issues/10378 now
10:33 mlankhorst: airlied: oh let me send you a post newyear hangover pull request. :)
11:49 eric_engestrom: DavidHeidelberg: indeed, I have noticed that commit is buggy
11:50 eric_engestrom: I have a feeling a number of recent va-api/vdpau bug reports are caused by that commit
11:51 eric_engestrom: maybe it should be reverted for now, and try merging it again now that collabora ci is back up and detects the bug (/cc pepp)
11:52 eric_engestrom: example of ci job failing because of that commit: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/53280917
12:04 eric_engestrom: ah, I see you (DavidHeidelberg) already posted an issue about it (https://gitlab.freedesktop.org/mesa/mesa/-/issues/10375) and pepp replied, so everyone is already aware :)
12:48 DavidHeidelberg: eric_engestrom: yup :)
15:09 zmike: eric_engestrom: is backport-to case sensitive?
15:33 karolherbst: jenatali: I've finished https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25568 in case you are up for more reviews :D
15:34 jenatali: karolherbst: I'm technically on vacation this week. I'll take a look Monday
15:34 karolherbst: ahh, didn't know :) enjoy your vacation then :)
15:36 jfalempe: tzimmermann, did you look at https://lists.freedesktop.org/archives/dri-devel/2023-December/434734.html ?
15:48 jenatali: karolherbst: You'll probably have to remind me next week :)
15:50 karolherbst: oh I will :D I might even add more changes, because apparently that `dladdr` trick won't work if you don't add `fPIC` or something 🙃 but maybe I can also ignore systems not suing fPIC....
15:51 tzimmermann: jfalempe, i briefly looked over it, but didn't understand the point
15:53 jfalempe: tzimmermann, it's really the Write-Combine of the internal RAM that affect the latency.
15:53 jfalempe: so for latency-critical application, we should have a way to disable it.
15:54 tzimmermann: last time we discussed this, we already knew that WC mode triggered the problem.
15:54 jfalempe: tzimmermann, yes but last time, it was the WC of the system RAM, which doesn't make much sense.
15:55 tzimmermann: the actual problem is that the RT process is not suffciently isolated from non-RT parts
15:55 tzimmermann: no amount of papering over will fix this
15:55 jfalempe: or that the WC mechanism of the CPU is not good enough to achieve good latency.
15:56 jfalempe: (in case of slow PCI device like MGA)
15:56 tzimmermann: you don't understand. the RT feature is not a function of the underlying hardware
15:56 tzimmermann: it comes from the design of the system as a whole
15:56 jfalempe: and software workaround for broken hardware is quite common I think.
15:57 tzimmermann: that hardware is not broken
15:57 tzimmermann: my first question is: why does the terminal interfere with the RT process?
15:58 jfalempe: it's not terminal related, even without VT/fbcon, writing to the video memory of the matrox interfere with RT process.
15:58 tzimmermann: yes, why?
15:59 jfalempe: I think when the CPU flushes the write combine buffer, it locks the whole PCI bus.
16:00 tzimmermann: that's what I mean: this is a problem of the system's overall design
16:00 tzimmermann: the designer of the RT system needs to take this into account
16:01 jfalempe: tzimmermann, it used to work with older kernel
16:01 jfalempe: they see that as a regression in the mgag200 driver.
16:02 tzimmermann: there's plenty of research out there, about how to make the individual HW components compatible with RT requirements by design (not merely by implementation)
16:03 jfalempe: I think mapping system RAM as WC, probably makes it disable WC on the mgag200 RAM, since copying from WC to WC memory is not possible.
16:03 tzimmermann: hence, i don't want patches that paper over problems that someone caused by mis-designing their computer system
16:05 tzimmermann: i think this patch should go into RHEL kernels for your customer, but not into upstream
16:06 jfalempe: We always try to upstream first, so that it can benefit all Linux users.
16:07 tzimmermann: how often do i have to say it: AFAICT this problem is happens because of your customer's system's poor design. it's not a problem that generally happens in the wild
16:07 jfalempe: For me it's more a compromise between performance or latency. the hardware allows to do both, but not at the same time. And users should be able to choose what fits their usage.
16:08 tzimmermann: if the system was correctly designed, it would take the PCI write's WCET into account. which seems to be 40 usec according to your measurements
16:10 tzimmermann: the system designer overcommitted to 10 usec AFAICT, hence it now fails its deadlines
16:12 jfalempe: tzimmermann, yes we can say don't use Matrox as it is outdated hardware, then why having a driver for it ?
16:14 tzimmermann: jfalempe, would you please try to address my points and concerns instead of shifting the topic
16:16 jfalempe: tzimmermann, the problem is that Matrox are not discrete GPU, so you can't remove it and put something else when you design such system.
16:17 tzimmermann: no, the problem is that the system's designer didn't even take the PCI write's WCET into account
16:18 jfalempe: it's working fine for other PCIE hardware, only Matrox slows the bus down.
16:19 tzimmermann: the designer still needs to take this into account
16:19 tzimmermann: as i said before. RT systems are designed; not just installed
16:20 jfalempe: Aspeed also uses Write Combine, and don't have such issue.
16:21 tzimmermann: an RT system with aspeed is something else and needs its own design and planning
16:25 mripard: tzimmermann: how the system was (poorly) designed is irrelevant. it's a regression, period.
16:26 tzimmermann: mripard, we never gave any guarantees
16:26 mripard: could they have done better? probably. But it was working so far, and it should keep working. Anything short of that is super user hostile.
16:26 mripard: sure, but that's true for pretty much the entire kernel
16:27 mripard: it's even said so in the license
16:27 mripard: I'm still not sure how that's relevant
16:27 tzimmermann: mripard, i'm not arguing against redhat shipping this patch in their kernels
16:28 mripard: so if someone was to reproduce that with a mainline kernel, you would consider patching it?
16:29 jfalempe: mripard, I've run the test with a mainline kernel. I always do that before sending thing upstream.
16:29 mripard: jfalempe: I know :)
16:31 mripard: that you're working for redhat is irrelevant too.
16:31 tzimmermann: mripard, this happens on mainline. to be clear, i'm not opposing performance fixes. if the general performance of the driver would go down, we could simply revert original patch. but this case happens in a single RT system where someone apparently overcommitted a resource. since we don't evern know what causes the interference, we cannot be sure that the patch even fixes the problem
16:32 mripard: it's something that used to work fine and doesn't. On mainline. It's a regression. It doesn't get simpler than that
16:33 tzimmermann: it's not, unfortunately
16:34 mripard: ok, so what level of explanation do you want to consider fixing that issue (or merging a patch that would) ?
16:35 tzimmermann: i'd first want to know how exactly the drm driver interferes with the RT process. because that's still unclear
16:35 jfalempe: tzimmermann, we reproduced it on multiple servers. It's just the one I have at home can't reproduce it, so it took me some time to get access to an affected server.
16:36 tzimmermann: jfalempe, are they all the same?
16:37 jfalempe: tzimmermann, let me check, but I'm pretty sure some HP and Dell systems have the issue.
16:38 tzimmermann: if this problem would affect every other user and/or use case, the patch would be a no-brainer
16:42 jfalempe: tzimmermann, at least one Supermicro Icelake server is affected. And I tested on a HP ProLiant DL110
16:44 tzimmermann: jfalempe, they both run the same userspace, i assume?
16:45 jfalempe: tzimmermann, yes
16:45 tzimmermann: jfalempe, i do have a dl120. maybe i can do a local test
16:49 tzimmermann: if this happens with physical vram (accordin to your email), it might affect other systems or processes. that would mean we should have a blacklist of system or something like this.
16:49 tzimmermann: jfalempe, i have to quite for today. let's talk tomorrow.
16:49 jfalempe: tzimmermann, you also need to write 0 to /dev/cpu_dma_latency if you want to reproduce low latency.
16:49 jfalempe: tzimmermann, ok thanks.
17:23 MrCooper: emersion: in case you're not aware, Markus Elfring is known for submitting mostly non-sense patches, and trying to start pointless arguments when called out
17:27 emersion: ah, ok
17:40 ccr: ehh. googling that name brought up a bizarre discussion on SQLite development forum.
17:52 zmike: mareko: ok so reading through that it looks like mostly I should just be replacing pb_buffer with pb_buffer_lean?
18:02 mareko: zmike: the perf is in the BO fence tracking, 1-level slabs, and delayed unique_id initialization for slabs
18:02 mareko: slab entries that is
18:02 zmike: hm
18:05 mareko: if you don't track fences per BOs, you can skip that one
18:05 zmike: yeah
18:06 zmike: the struggle to remember how to graphics after a long break is real 🤕
18:49 mareko: a distant goal might be to make zink work with viewperf13+2020
18:52 mareko: DavidHeidelberg: how close are we to increasing the libdrm version in mesa?
18:57 zmike: it doesn't work already?
19:02 zmike: mareko: is this through wine? or is there a native version
19:15 JoshuaAshton: If I send something to amd-gfx but forgot a Fixes tag and it was applied already, is there a way to tag something as "probably should be backported"?
19:15 JoshuaAshton: Or is it too late :frog:
19:17 kisak: until it goes upstream to torvalds, it's a negotiation with the subsystem maintainer?
19:19 JoshuaAshton: I asked anyway https://lists.freedesktop.org/archives/amd-gfx/2024-January/102846.html
19:23 mareko: zmike: there is a native version, free for ISVs
19:23 zmike: ah
19:23 zmike: that explains it
19:23 zmike: do I have to contact them or something? I didn't see it on the site
19:23 mareko: no
19:24 mareko: and it doesn't work
19:24 zmike: haha
19:24 zmike: distant goal indeed
19:26 mareko: it's still good for testing performance because the testing can be automated, it takes me 50 minutes while AFK to run both viewperf suites, gputest, unigine and some others
19:27 zmike: so you run in wine?
19:27 mareko: never
19:27 zmike: then I'm confused...you said the native version doesn't work?
19:28 mareko: there is a native version, and it doesn't work with zink only
19:28 zmike: ah
19:28 zmike: yes
19:28 zmike: I'm trying to find that native version now to download and test
19:30 mareko: https://gwpg.spec.org/benchmarks/benchmark/specviewperf-2020v3-0-linux-edition/ - Valve might need to pay, not sure
19:31 zmike: hm
19:31 mareko: https://spec.cs.miami.edu/gwpg/gpc.static/vp13linuxinfo.html
19:32 zmike: since I'm acting in the capacity of FDO it's probably fine
19:33 mareko: all work I do outside of my office hours is still owned by AMD
19:37 zmike: not the case for me
19:38 JoshuaAshton: I would recommend contacting them to be certain
19:38 JoshuaAshton: Valve is a computer hardware and software vendor
19:39 zmike: that's true, but this would only affect my billable hours
19:40 zmike: when I take off my Big Triangle hat, I am again just an unwashed plebeian hobbyist like everyone else
19:40 JoshuaAshton: Can you be a vendor of free software
19:40 JoshuaAshton: Many philosophical questions
19:40 zmike: deep thoughts
19:42 Lynne: in ffmpeg, we have an Elvis Presley, a pseudonym used by anyone who cannot publish their work for one reason or another
19:42 zmike: tremendous
19:43 JoshuaAshton: Sounds like crappy situation to be in *badum tiss*
19:43 zmike: maybe we should have Gordon Fr33man
19:45 mareko: zmike: since you said it, you can't use that name now ;)
19:45 zmike: dang, it'll be a real challenge to come up with something else
19:47 zmike: that's all for the distant future though, cuz for now I've got at least 6 hours of lavapipe cts to push through
19:51 airlied: only 6? I had 18hrs projected run yesterday :-P, but I ctrl-c once I paged back in the horror show I'd forgotten about over break
19:51 zmike: 🤕
19:51 airlied: atexit is the devil
19:51 zmike: yes
19:52 airlied: atexit with piglit test + glthread + tc + zink + lavapipe + llvm is quite the horrors
19:52 mareko: just llvm
19:52 airlied: piglit test renders a frame then exits, the exit causes atexits to be called, one of which destroys the context which flushes the rendered frame
19:53 airlied: but only after llvm atexit has been called
19:53 mareko: you need ac_llvm_run_atexit_for_destructors
19:54 airlied: oh that does look like it might fix it
19:55 airlied: thanks, that might save my sanity
20:46 airlied: mareko: thanks, porting that to gallivm worked, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26883
20:56 mareko: np
21:58 agd5f: JoshuaAshton, we can add the tags when it gets applied. Just waiting for the display team to review it
22:07 mareko: vulkan on softpipe when? ;)
22:09 zmike:whacks mareko with the newspaper again
22:09 zmike: no.
22:12 airlied: I'd rather rm softpipe :-P
22:15 mareko: but you could make it faster by replacing TGSI with a NIR interpreter ;)
22:16 JoshuaAshton: agd5f: Thanks!
22:19 airlied: not sure it would be faster, but you could make it something else :-P
22:19 airlied: maybe someone could add MSAA
22:19 airlied: (narrator: I wrote softpipe msaa once, and got it 99% of the way before I noped out)
22:27 theanorak_: hello!
22:27 theanorak_: i hope everyone is having a great day
22:28 theanorak_: i'm interested in contributing to NVK. I have a gtx 1650 mobile. Any good documentation or tips related for a first contribution?
22:30 kisak: #nouveau is probably a closer channel to the topic
22:39 theanorak_: thanks, i'll head into the channel and ask about it
22:39 theanorak_: Hope you have a great day!
23:17 karolherbst: airlied: is there any reason to keep softpipe still?
23:17 karolherbst: guess for systems not supporting llvm? do we care about any of those?
23:34 jenatali: FWIW we use it as the swrast that handles things like rasterpos, since LLVM has to be statically linked on Windows and accelerating that isn't worth a full copy of LLVM in our driver DLL
23:36 airlied: that is just draw I think
23:36 airlied: though I'd like to gut draw of tgsi as well :-P
23:44 jenatali: Yeah, but draw can use LLVM or not. Isn't draw essentially the entire guts of LLVMPipe/softpipe?
23:47 karolherbst: thre is also tgsi_exec
23:47 airlied: it's everything that isn't a binner/rasterizer/fragment/compute/mesh stage
23:47 karolherbst: which is kinda a CPU simulator of TGSI instructions
23:51 airlied: tgsi_exec is the shader engine for draw/softpipe in tgsi mode
23:51 airlied: just need nir_exec :-P
23:52 karolherbst: ez, just use the consting folding expressing
23:52 karolherbst: *expressions
23:52 karolherbst: (and handle intrinsics)
23:53 karolherbst: finally a driver which has all the nir features
23:58 airlied: I'm surprised gfxstrand has never done it for the lols