17:38austriancoder: tanty: I am happy for every review I get: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8295
18:13ajax: - pass: 15819
18:13ajax: - fail: 83
18:13ajax: + pass: 338
18:13ajax: + fail: 15564
18:13ajax: not exactly the piglit diff you want to see...
18:14anholt: new game: how low can one get the passrate in a single commit?
18:15alyssa: anholt: My usual game is seeing how few failures you can get whilestill being totally broken :>
18:15imirkin: alyssa: just render all green for that
18:15alyssa: bonus points if you are like failing a single test of hundreds in the swizzles.* category
18:15ajax: i was going to suggest #define GET_DISPATCH() NULL as the easiest way to blow up everything, but the worrying thing is there's probably some piglits that would still pass
18:16anholt: I've got a MR up for some super broken msaa rendering that we only noticed because some tangential change made deqp consistently catch just one of the many broken pixels.
18:21zmike: does breakage from not doing make clean count? if so I'm at 99.9%
18:21alyssa: ...why would you have to make clean?
18:33Prf_Jakob: keithp: You can have my tested-by on the first commit of your present-timings branch, :) I put that on mesa master and ran it with radv. Both X11 and direct mode seem to work.
18:34zmike: because build systems are hard
18:34Prf_Jakob: keithp: Wondering if you are looking to get at least that commit upstream?
18:35Lyude: Could someone update the drm-misc-fixes branch? or should I just push fixes to drm-misc-next? ( mripard ?)
18:38keithp: Prf_Jakob: thanks for testing. We should wait until that extension is stable before merging upstream?
18:38keithp: I know of at least one major change (sadly, not public yet) that needs to happen
18:43Prf_Jakob: keithp: The Google extension is stable right?
18:43keithp: yes, good point
18:44keithp: could merge to that point; that would give most of the hooks needed for the EXT extension too
18:44Prf_Jakob: That would be awesome, as it gives us at least something to work with.
18:44Prf_Jakob: Other then reimplementing all of the WSI code in order to get displaying timing in direct mode.
18:45keithp: Prf_Jakob: urf
18:45keithp: I was hoping to get both extensions merged, but then realized the EXT one was stuck behind a pending KHR extension
18:46keithp: hoping to have that un-stuck shortly though!
18:46Prf_Jakob: I promise I'll get somebody to review both MRs :)
18:47keithp: sounds like I should create a PR for the google extension patches
18:47Prf_Jakob: That would be kind
18:48Prf_Jakob: I just grabed the first patch and cherry-picked it on master, applied cleanly and work.
18:48jekstrand: pendingchaos: Looking at !4202.... Don't we already have a I/O vectorization pass for shader IO that tarceri wrote? Why not use that one for RADV?
18:59pendingchaos: jekstrand: what's that pass called?
19:00keithp: Prf_Jakob: I had recently rebased that series, so I'm not *that* surprised that it applied cleanly
19:02jekstrand: pendingchaos: nir_lower_io_to_vector
19:04pendingchaos: ok (it looks like you wrote that btw)
19:05pendingchaos: not sure I remember why the MR uses the load/store vectorizer instead
19:05pendingchaos: might have been to vectorize VS inputs and across slots
19:06jekstrand: Oh, I guess I did write that. :-)
19:09pendingchaos:makes a note to try nir_lower_io_to_vector+nir_opt_combine_stores tomorrow
20:14anholt: mareko: any clues on what's up with nir uniform linking in !8044?
20:30mareko: anholt: no, I just discovered the valgrind warning
20:31anholt: there's something about uniform location assignment that changes with the gtn and ntt path in st instead of gtn in st and ntt in softpipe.
20:42anholt: more git grep of PREFERRED_IR needed. found it.
20:45ajax: anyone know the semantic difference between PIPE_BIND_DISPLAY_TARGET and PIPE_BIND_SCANOUT?
20:45anholt: also, yay, looks like another pile of code we can delete once we get the gtn MR and the delete-classic-dri MR.
20:45anholt: ajax: I think "vague, handwavy, undefined"
20:48anholt: pipe_bind_shared is related and really important, though ("will you ever ask for an fd or gem handle?").
20:54ajax: that doesn't seem like a thing you can know at resource_create time
21:02Prf_Jakob:makes old school harddisks noises as he swaps in old knowlage.
21:03bnieuwenhuizen: IIRc you "know" the shared one because you can only get fds for EGL/GLX images?
21:10Prf_Jakob: ajax: Can't say I remember more then scanout is (or was at the time I was using it (added it?)) intended for scanout, while display target might have had it's roots from Windows and ment you could show it on screen.
21:13ajax: bnieuwenhuizen: if i'm glamor then at any time some X client might ask for an fd to the texture storage for a pixmap
21:22bnieuwenhuizen: ajax: but all those GLAMOR textures get allocated via the mesa dri interface right?
21:22bnieuwenhuizen: instead of GL
21:38anholt: ajax: glamor promotes pixmaps to sharable storage through gbm allocation at the point that someone asks for a name, by doing a copy.
21:39ajax: ah, right. i'm sure i should have known that already.
21:40mareko: FWIW, PIPE_BIND_SCANOUT means displayable for hw drivers and PIPE_BIND_DISPLAY_TARGET is ignored
21:47imirkin: nouveau has some confused handling of DISPLAY_TARGET
21:48imirkin: there's some value in distinguishing between "buffer that the winsys will take" and "buffer that can be pageflipped to"
22:09jenatali: Is there support for dynamic promotion from "buffer that the winsys will take" into "buffer that can be pageflipped to"? We built that on Windows and the heuristics to allocate stuff the right way is... messy
22:24anholt: jenatali: X11 present has feedback information for requesting the upgrade, but I don't know that anyone ever hooked it up in mesa.
22:25jenatali: anholt: I wish we did it via feedback... Is there feedback for downgrading too?
22:44emersion: wayland has something similar in the works
22:45jekstrand: jenatali: We usually handle it on Intel by just always allocating something flippable.
22:45alyssa: jekstrand: No profanity in #dri-devel.
22:45jekstrand: jenatali: Until Gen9 that is. Then it gets messy because scanout can do compression, some of the time.
22:45emersion: jekstrand: but depends what the modifier is, right?
22:45jenatali: jekstrand: Yeah, that's the kind of situation I'm thinking of
22:45jekstrand: emersion: Well, then there's the modifiers mess. :-)
22:46emersion: GBM use flags, blah blah blah
22:46jekstrand: emersion: I believe the X11 protocol for modifiers does support negotiation to change but I don't think it ever got implemented properly in bare X
22:46emersion: yeah, haven't seen anything implementing it
22:46jekstrand: I don't think re-negotiation was ever implemented for Wayland.
22:46emersion: even modifiers are barely implemented in modesetting
22:47jekstrand: Don't remind me. :-(
22:47emersion: re-negociation is WIP: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8
22:47emersion: missing reviewers…
22:51jekstrand:feels very slightly guilty for having ignored that for a year.
22:54jekstrand: But only slightly!