00:03 dcbaker[m]: ajax: this sounds very par for the course with nvidia
00:04 dcbaker[m]: Compat profile is all "wave hands at what happens with you use a 1.0 and 4.0 feature together"
00:04 ajax: right but core profile
00:05 dcbaker[m]: I
00:05 ajax: i mean they expose it in the compat profile _too_ but at least that makes sense
00:05 dcbaker[m]: I'm just saying nvidia has lots of "we didn't think this through" compatability features
00:05 dcbaker[m]: add this to the list :)
05:44 dcbaker[m]: mareko: thanks!
13:14 neobrain[m]: Hey! We (=the radv folks) have written a radv-specific issue template for Mesa, which we hope will improve the quality of incoming issue reports for us. I posted this in !7551 a few weeks ago and nobody has complained so far, but I wanted to make sure there are no objections to us adding this new template. Any opinions?
14:58 tlwoerner: what are people mostly using these days for benchmark/compliance testing?
14:58 tlwoerner: specifically, is https://gitlab.freedesktop.org/mesa/parallel-deqp-runner considered current?
14:58 tlwoerner: or https://source.android.com/devices/graphics/deqp-testing
14:59 tlwoerner: 3) https://github.com/KhronosGroup/VK-GL-CTS
14:59 tlwoerner: 4) glmark2
15:05 pendingchaos: for OpenGL or Vulkan?
15:07 pendingchaos: parallel-deqp-runner isn't a test-suite, it makes it easier/faster to run the tests in https://github.com/KhronosGroup/VK-GL-CTS
15:09 tlwoerner: either, or both? VK-GL-CTS seems to do both?
15:10 tlwoerner: ooh, maybe if there were a matrix somewhere with a list of suites and what they test?
15:12 dschuermann: VK-GL-CTS runs single-threaded and stops on crashes, parallel-deqp solves these two restrictions, but if your machine hangs, it's way harder to find the causing test
15:12 pendingchaos: for testing Vulkan, I usually test correctness by running VK-GL-CTS with parallel-deqp-runner
15:12 pendingchaos: and use various games as benchmarks
15:12 pendingchaos: to test both correctness and performance, I also compile a large amount of shaders using Fossilize to see if any compile differently (or not at all)
15:12 pendingchaos: for OpenGL, I think people use VK-GL-CTS and piglit
15:12 dschuermann: and shaderdb
15:13 tomeu: tanty: will give a look to it tomorrow if nobody else from Collabora has beat me to
15:16 tanty: thanks a lot!
15:36 Sumera[m]:sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/HdPPvQNIKcsYFXQsrXIAQKHg/message.txt >
15:37 pendingchaos: danvet: ^
15:39 Sumera[m]: oops, should have pastebinned instead I guess
15:41 emersion: or split into smaller, logical one-line messages
15:43 Sumera[m]: emersion: yes, going to do that next time
15:50 danvet: Sumera[m], yeah so yeah revised idea: I think keeping the virtual connnector hotplug could be intersting
15:50 danvet: but the removing/adding the writeback at runtime is really not something a real gpu would do
15:51 emersion: vsyrjala: ack on https://patchwork.freedesktop.org/patch/407150/ ?
15:51 danvet: I do still think hotplugging entire vkms device instance would be the best first step
15:52 danvet: but we can definitely keep the writeback and connector stuff for now as examples
15:52 danvet: Sumera[m], I think easier if I type up something in email
15:53 danvet: Sumera[m], or should I add it to the google doc?
16:00 vsyrjala: emersion: ack
16:00 emersion: thx!
16:20 dschuermann: can someone tell me which meson build options I need to enable for softpipe to test GLES31 CTS?
16:35 ajax: dschuermann: -Dgallium-drivers=swrast and then (if that happened to also build llvmpipe, which it probably did) run with GALLIUM_DRIVER=softpipe in the envionment
16:37 dschuermann: ah, I tried dri-drivers=swrast
16:38 ajax: yeah, sorry, that's the old pre-gallium software renderer
16:40 dschuermann: anholt: I have an idea what goes wrong with !6666. I think the vectorizer fights with some other NIR pass and creates an infinite loop
16:47 dschuermann: nvm
17:16 danvet: j4ni, any i915 fixes?
17:17 danvet: I'm planning to do a pull tomorrow morning
17:17 danvet: but can delay if you're sitting on some stuff
17:17 danvet: dolphin, ^^
17:30 dschuermann: anholt: I'm pretty sure the softpipe CTS fails are unrelated to !6666, but only uncovered. If you want to cover them up again, you can just move the vectorizer after the optimization loop ;)
17:49 anholt: dschuermann: it's not in the cts, it's a specific shader_runner test
17:50 anholt: the crash is in the vectorizer as of your commit to the vectorizer
17:50 dschuermann: o_O
17:50 anholt: shader-db, sorry
17:51 dschuermann: how can I reproduce? I saw a couple of CTS fails as well, but the NIR looks completely fine
17:51 anholt: LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=softpiipe ./run shaders/closed/steam/left-4-dead-2/high/3764.shader_test
17:55 dschuermann: sorry if this is a stupid question but what shader runner?
17:56 anholt: you have shader-db right? do you have a pile of closed-source shaders?
17:57 dschuermann: not for opengl, we use either pipelinedb or fossilize
17:57 dschuermann: I can build shaderdb, though. If you send me the shader, I can have a look
18:17 ajax: src/gallium/tools/trace/*.py are still python2. charming.
19:09 dcbaker[m]: greypilgrim: all upstream work goes on in master
19:09 dcbaker[m]: at the appointed time someone (usually me) creates the 21.0 and staging/21.0 branches
19:10 dcbaker[m]: all nominations for stable branches move tot he staging/X.Y branch, and then at release time the X.Y branch is rebased on that branch
19:10 dcbaker[m]: the staging branches allow force pushes to remove bad patches, the non-staging branches do not allow force pushes
19:11 dcbaker[m]: commits can be nominated by putting a valid `fixes:` tag or `cc: X.Y <mesa-stable>` tag in the commit message, or by creating a pull request against the staging/X.Y branch
19:18 dcbaker[m]: np
19:23 kisak: ^ that looks like a one-sided response to a question that wasn't asked. I'm guessing something didn't make it over the matrix bridge
19:25 dcbaker[m]: very likely
19:26 dcbaker[m]: greypilgrim: it looks like you don't have a freenode account associated with your matrix account, so I can see you're messages, but no one on the IRC side can, FYI
19:27 HdkR: oh, that's what the [m] means
19:28 HdkR: TIL
19:33 dcbaker[m]: tanty: I'm really sorry I forgot to look at those 😅, I've reviewed the three that I feel qualified to look at
19:41 kisak: and yet greypilgrim[m] is a user here on the freenode side
19:42 dcbaker[m]: yeah, not correctly associated. I think my [m] has gone away? I don't have a "native" irc client connected to freenode anymore.
19:43 kisak: no, we see you as dcbaker[m]
19:58 dcbaker[m]: ajax: do you have a trace I can use. That looks like it'd take me about 20 minutes to port if I had some test input...
20:10 airlied: danvet: posted a nouveau regression fix might want to land that in the pull as well
20:10 airlied: I think christian has a one liner qxl fix floating around as well
20:15 dcbaker[m]: ajax: wip/2020-12/trace-tools-py3 on my gitlab, if you're interested
20:15 danvet: airlied, not seeing a qxl patch from köing
20:16 danvet: I'll vacuum up the nouveau one
20:25 airlied: danvet: yeah it was only sent to someone to test, I've asked him to drop it somewhere for real
20:25 airlied: https://lore.kernel.org/lkml/7cb43d5b-4e6a-defc-1ab6-5f713ad5a963@amd.com/2-0001-drm-qxl-don-t-allocate-a-dma_address-array.patch
20:25 airlied: https://lore.kernel.org/lkml/7cb43d5b-4e6a-defc-1ab6-5f713ad5a963@amd.com/
20:26 danvet: ickle, holler if it's me causing the drm-tip rebuild conflict
20:26 danvet:just pushed
20:26 danvet: I mean if there's anything left after you cleaned up
20:26 ickle: fixing up a conflict right now
20:54 ajax: dcbaker[m]: ajax.fedorapeople.org/g.trace
21:07 dcbaker[m]: greypilgrim: dri-devel (and a bunch of other channels) require that you're registered to speak because of spammers
21:08 dcbaker[m]: you just need to register as your freenode nick: https://gist.github.com/fstab/ce805d3001600ac147b79d413668770d
21:13 dcbaker[m]: ajax: I've updated my branch, it should actually work now 🙂
21:14 dcbaker[m]: also, that's some real java in python code
21:14 dcbaker[m]: haven't seen that kind of python in a long time
21:21 greypilgrim: test 123
21:23 jljusten: greypilgrim: now tell dcbaker[m] how to get rid of the "[m]" :)
21:25 dcbaker: craftyguy: happy?
21:25 dcbaker: erp
21:25 dcbaker: sorry craftyguy
21:25 dcbaker: I meant: jljusten , happy?
21:25 craftyguy: always
21:26 jljusten: :)
21:26 dcbaker: Yeah, never need to worry about you craftyguy
23:32 zmike: is fdo having ssl issues? marge is failing...
23:33 airlied: yeah ci-fairy failed for me on my last CI run
23:33 zmike: ok so it's not just me
23:39 airlied: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/6242702
23:39 anholt: known on #freedesktop
23:39 daniels: known, just fixed
23:39 airlied: anholt: ah cool
23:39 anholt: they're working on some ingress stuff
23:43 anholt: daniels: note that you need to restart jobs as well as reassign to marge, or she bails when she gets around to looking at it
23:43 anholt:has restarted a few mrs now
23:43 daniels: oof, sorry
23:43 daniels: forgot about that one