00:43 alyssa: imaginapple, mali, and videocore are the 'true' tilers (-:
01:53 tarceri: Is there anyone online that would be able to run a piglit test for me on the Nvidia OpenGL bianry driver?
01:54 tarceri: the hdd died in the machine I normally use for testing
01:57 tarceri: actually nevermind
08:08 Company: I have a question
08:08 Company: because my mental model can't handle this case
08:08 Company: There is external code that exports a dmabuf from GL
08:08 Company: in this case Epiphany
08:09 Company: and it doesn't do any syncing
08:09 Company: however, when GTK imports that dmabuf with the GL renderer, everything works fine
08:10 Company: but when GTK imports that dmabuf with the Vulkan renderer, things break
08:10 Company: and I don't get why GL works
08:10 emersion: vulkan does explicit sync
08:11 Company: what do you mean?
08:12 Company: I'm explicitly importing the sync fd from the dmabuf if there is one
08:12 Company: but there isn't one
08:13 Company: actually, that's not even how this codepath works, now that I think about it
08:13 Company: this code path probably does a glReadPixels() on the imported dmabuf
08:14 MrCooper: the answer to "how does GL work?" is via implicit sync
08:15 MrCooper: demarchi: FWIW, mailman mangles Cc only if the list subscriber enabled that option in their subscription
08:15 Company: how does "implicit sync" work here?
08:18 Company: does that just mean that if 2 apps use GL it'll just always work and if one app wants to use Vulkan, things will always break?
08:19 Company: that can't be, then all compositors using Vulkan would be broken
08:23 MrCooper: implicit sync works via the dma-buf's synchronization object
08:23 MrCooper: the Vulkan implementation can make that work as well
08:23 Company: right, the one that you'd need to import on Vulkan
08:24 Company: and the one that I'm pretty sure Ephy doesn't use
08:24 MrCooper: Ephy draws using GL?
08:24 emersion: do they glFlush()?
08:25 emersion: without glFlush() then the implicit fence is not populated
08:25 MrCooper: then it would break with GL in the importer as well
08:25 Company: Ephy has 2 processes
08:25 Company: the UI process and the webpage process
08:25 Company: and they communicate via dmabuf
08:26 Company: the UI process runs GTK
08:26 Company: and the web process runs whatever webkit does
08:27 Company: if you have a recent GTK at hand, you can just reproduce it with GSK_RENDERER=vulkan epiphany
08:27 MrCooper: presumably webkit uses GL, so the GL driver should populate the dma-buf synchronization object on glFlush(); which driver is this?
08:29 Company: happens on Intel and AMD
08:31 MrCooper: does mesa_glthread=false avoid it by any chance?
08:35 dj-death: Company: we should be doing implicit sync in Anv with imported BOs
08:36 dj-death: Company: maybe you're just getting lucking that the work submission between the importer/exported is happening in the right order with the GL renderer
08:36 dj-death: s/lucking/lucky/
08:36 dj-death: implicit sync will not be available with the new kernel driver
08:37 Company: yeah, that's what I'm wondering
08:37 Company: if ephy is just getting lucky
08:38 Company: but it seems a rather big guess, because it's been doing that for a year now in a released version
08:41 MrCooper: dj-death: you still need to make it work in user space though, by extracting fences from the implicit synchronization object?
08:41 dj-death: MrCooper: for wsi that's happening yeah
08:41 dj-death: MrCooper: not for buffers imported
08:42 Company: they use gbm to allocate, then send the fd over to the GTK process and then eglCreateImage() in both processes
08:42 MrCooper: I see, so it's up to the application in this case?
08:42 dj-death: yeah
08:43 MrCooper: anyway, sounds like GTK is trying to do it, there are no fences though for some reason
08:43 MrCooper: Company: if there are no fences in the dma-buf after glFlush returns, that's a bug
08:44 dj-death: there should be one inserted by the kernel I think
08:44 dj-death: at least on i915
08:44 dj-death: xe is different
08:44 MrCooper: with xe it has to be done by iris
08:45 Company: they do a glFlush() and then send a frame event to the GTK process
08:45 Company: https://github.com/WebKit/WebKit/blob/a011563227e99a7fb9f3d81a7ec7645d538b71ce/Source/WebKit/WebProcess/WebPage/dmabuf/AcceleratedSurfaceDMABuf.cpp#L579
08:47 Company: and when they receive the buffer, they just queue_draw() on the GTK side
08:47 Company: https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/gtk/AcceleratedBackingStoreDMABuf.cpp#L467
08:48 Company: so I suppose as long as both processes use the same GPU queue, they will commit their commands in order and everything works out smoothly?
08:50 Company: and with the Cairo renderer (and I think Vulkan, too) this code doesn't work, because the GTK process does glReadPixels() (or glGetTexImage()) which doesn't use the GPU queue
08:51 Company: and if Vulkan actually straight used the dmabuf, it would probably work by the same accident
08:52 MrCooper: glReadPixels & glGetTexImage is GL, so should work the same as with GL otherwise
08:52 MrCooper: there's no accident, it's supposed to work
08:52 Company: if you glReadPixels() in a different process?
08:53 MrCooper: there seems to be a bug so that the dma-buf doesn't have fences after glFlush
08:53 dj-death: Company: the queues are independent
08:53 dj-death: Company: but the fences attached to the buffers should be taken into account for the work ordering dependency
08:53 MrCooper: or maybe GTK doesn't retrieve the fences correctly
08:54 MrCooper: that actually seems more likely :)
08:54 Company: GTK doesn't do anything - other than creating an EGL image and call glReadPixels() on it whenever it gets a message
08:54 MrCooper: and that seems to work fine?
08:54 Company: no
08:55 Company: that's the thing that doesn't work
08:55 MrCooper: I mean the other GL usage
08:55 Company: the other usage seems to work, yes
08:55 Company: it's what you get when you run epiphany today
08:55 MrCooper: glReadPixels not working might be a separate Mesa bug then
08:55 Company: where it creates an EGL image and when it gets a message, uses that as a source in a shader
08:57 Company: afaiu the glReadPixels path has never worked for Ephy
08:57 Company: because they disable that path when GTK uses the Cairo renderer
08:57 Company: and the Cairo renderer does support reading from GL textures
08:58 MrCooper: GL is GL, there's no distinction between different GL APIs for this
08:59 pq: There are no requirements like you have to re-do glEGLImageTargetTexture2DOES to make new implicit fences effective, are there?
08:59 Company: I'm saying that if there's a bug with glReadPixels, it's an old bug
08:59 MrCooper: right
09:01 MrCooper: pq: I've heard almost any possible opinion on whether or not that's necessary per the spec :/ shouldn't be necessary in practice with those Mesa drivers though
09:01 pq: alright
09:02 Company: I'm just wondering if Ephy should send some explicit sync object in their frame event
09:02 Company: or if glFlush() should be enough
09:03 MrCooper: Company: the former is needed for nvidia, the latter suffices with Mesa
09:03 Company: is there example code for how to do that?
09:04 Company: it'll be similar to how it works in Vulkan I guess, but I'd like to avoid googling how to turn a GLsync into an fd and ending up with a wrong guide
09:05 pq: FWIW, Weston seems to be calling glEGLImageTargetTexture2DOES on every update, but also Weston has/is been used on all kinds of drivers.
09:05 MrCooper: pq: mutter & Xwayland only ever call it once
09:06 Company: GTK requires you to recreate the GdkTexture, too - but nothing stops you from calling it only once and reusing the GL texture id
09:07 Company: which seems to be what ephy is doing
09:08 MrCooper: Company: EGL_ANDROID_native_fence_sync allows retrieving a sync_file from a GLsync
09:11 Company: and then you explicitly attach that to the dmabuf
09:11 Company: then you send the message to the GTK process, and make the GTK process reimport the dmabuf
09:14 MrCooper: explicit sync would be sending the sync_file directly, no messing with the dma-buf synchronization object
09:15 MrCooper: the latter can be used as a side channel though, yeah
09:15 Company: hrm
09:16 Company: that would need some way to import sync files in GTK
09:16 Company: gdk_dmabuf_texture_builder_set_sync_fd (builder, fd);
09:16 Company: or something
09:16 Company: https://forums.debian.net/viewtopic.php?t=157612
09:17 Company: seems that indeed ephy is randomly broken on nvidia
09:19 pq: gdk_dmabuf_texture_builder_set_sync_fd sounds off, shouldn't the fd be sent with every update rather than once on initial import?
09:19 Company: GTK's textures are immutable
09:19 Company: so you must reimport them anyway
09:19 pq: so no-one re-uses them? Didn't you just say some programs fish out the texture id and re-use anyway?
09:20 Company: you can reuse the dmabuf
09:20 Company: but not the GTK object
09:20 pq: okay
09:21 Company: the gtk object tracks a frozen state for some pixel
09:21 Company: *pixels
09:21 Company: "texture" is a misnomer really, but I didn't have a better name, and terms like "image" etc were all taken by X or Wayland APIs
09:23 pq: a name for pixel buffer contents frozen at an instant in time... good question
09:24 pq: "frame"
09:25 Company: that term is used for the concept of "rendering a frame"
09:26 pq: yes, seems fitting to me
09:27 Company: what you really want is the ability to constify pixels and then later unconstify them, but using 2 different types
09:28 Company: wl_buffer and cairo_surface_t suffer from that, too - you never know if you're allowed to write to it currently
09:28 Company: from just looking at it
09:30 pq: yeah, not by the type indeed. That's an interesting idea to implement in Wayland IPC context.
09:31 Company: Wayland has it a bit easier because there's just 2 potential consumers of a buffer
09:31 pq: something like attaching a wl_buffer will destroy the wl_buffer but give you back a new wl_locked_buffer object referring to the same underlying buffer. You just cannot do anything with a wl_locked_buffer until it delivers an event that destroys it and gives you a new wl_buffer.
09:31 Company: yeah, something like that
09:31 Company: except that doesn't quite work
09:32 Company: if you want to use the same wl_buffer for 2 surfaces
09:32 pq: Too bad the Wayland IPC story around server-side created objects is full of pitfalls.
09:33 Company: so you need to make the lock/unlock explicit I think
09:34 pq: yeah, I just wonder what happens with the unlock if you attach the same locked buffer to multiple surfaces...
09:34 Company: the unlock fails
09:34 pq: protocol messages cannot fail.
09:34 pq: oh but that's not a problem like the wl_buffer.release event is a problem
09:34 Company: well, the unlock would not give you a buffer
09:34 pq: actually, there is a race
09:35 pq: client cannot initiate unlock, it would need to be the server
09:35 MrCooper: Company: the contents of a GTK texture backed by a dma-buf can't really be "immutable", it would need to copy to a separate non-shared buffer for that
09:35 Company: but I don't think this works on a protocol level
09:35 pq: but while the server is sending unlock event, the client could be using the locked object even more, leading to protocol error
09:36 Company: MrCooper: "immutable" means everybody promises to not touch it
09:36 Company: MrCooper: same as the contents of a wl_buffer
09:37 pq: so we'd need something like server sending event "you should be able to unlock now", client sending unlock request, and then we also need a server reply if the unlock actually worked. Ugh.
09:37 Company: MrCooper: the important part is that the texture has to stay immutable until all references to it are released (at which point the destructor will call a callback provided upon creation)
09:38 Company: MrCooper: and it's up to the creator of the texture to ensure that happens
09:38 pq: while modern development is going in the direction of passing fences around that may trigger later, which is a totally different direction.
09:39 pq: so I think the locked/unlocked API must be invented purely client-side, it's not a good match for IPC
09:39 Company: pq: I agree on that very much
09:39 pq: yay :-)
09:39 Company: also because IPC cannot guarantee stuff stays untouched
09:40 Company: mutter can't stop the client from writing to a dmabuf, even if it's put in a locked_buffer
09:40 Company: so the benefit is client-only, as in its main use is to catch bugs in your code
09:42 Company: so something like Rust's borrow checker
09:53 MrCooper: Company: which epiphany process calls gsk_vulkan_image_new_for_dmabuf ?
10:00 Company: MrCooper: none
10:01 Company: I realized that Ephy uses GL textures not dmabuf textures, so it goes via glReadPixels()
10:06 MrCooper: then there seems to be a Mesa bug there
10:08 Company: it goes via gdk_gl_texture_new()
10:08 Company: https://paste.centos.org/view/55405dc1 is the stack trace for that
10:09 Company: and that goes into https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/gdkgltexture.c#L182
10:09 Company: which ends up in the GLES branch and calls glReadPixels()
10:10 Company: but it doesn't work with GL either
10:13 MrCooper: can you file a Mesa issue?
10:14 Company: hrm
10:14 Company: should probably get the Ephy people involved?
10:16 MrCooper: what for?
10:17 MrCooper: it's between glFlush & glGetTexImage / glReadPixels, all in Mesa
10:18 MrCooper: mesa_glthread=false doesn't help BTW
10:28 Company: MrCooper: I feel both unqualified to describe the actual bug, nor to explain what the code is doing
10:29 Company: I just dug through a github repo trying to make sense of it
10:59 Company: MrCooper: it's not a mesa bug
10:59 Company: Ephy creates a GdkTexture and reuses it in subsequent draw calls
11:00 Company: and because textures are immutable, the Vulkan renderer goes "oh, same thing as before" and reuses its cached copy
11:00 Company: and it works on GL because GL uses the dmabuf directly and doesn't go via glReadPixels()
11:01 Company: and the original image that gets cached is the first frame - which in a browser almost always is empty while it's loading the page
11:02 Company: which is why it looks like things are broken
11:03 MrCooper: phew, good catch
11:03 MrCooper: so it's related to the issue I pointed out with dma-buf-backed textures not really being immutable
11:04 Company: yeah
11:04 Company: and people not being diligent with when they may or may not touch texture memory
11:05 Company: so it was good that we talked about that, because it randomly hit me "maybe that's the reason" and then I checked
11:06 Company: Ephy also has no buffer release event
11:06 Company: so there's much brokenness there
11:06 MrCooper: oh dear
11:08 Company: I take that back
11:08 Company: but it doesn't wait for GTK to release the buffer
11:10 MrCooper: buffer as in GdkDmabuf ?
11:12 Company: sorry, texture
11:13 Company: Ephy doesn't wait for the GdkTexture's release callback
11:14 MrCooper: a GdkTexture is supposed to be immutable though?
11:14 Company: supposed, yeah
11:14 MrCooper: what's the release callback for then?
11:14 Company: releasing the backing texture
11:15 Company: think of it as the buffer release callback in Wayland
11:15 MrCooper: that's needed to allow the client to modify the buffer contents again
11:15 Company: yeah
11:15 MrCooper: which doesn't apply to an immutable texture
11:16 Company: the buffer contents are only immutable as long as a texture refers to them
11:16 MrCooper: anyway, I'm probably missing context, just idle curiosity
11:17 Company: I'll give you an example: GtkGLArea
11:17 Company: it sets up everything and then creates the GDK texture at https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkglarea.c#L784 by passing the release_texture callback
11:18 sima: dj-death, I thought iris would need to do the implicit sync dance for any shared dma-buf
11:18 sima: otherwise things just break too badly since that's how it works everywhere else on mesa linux gl
11:19 Company: and the release_texture function at https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkglarea.c#L703 puts the texture back into the pool of free textures
11:19 Company: it sets holder = NULL but that's how we identify "free" textures
11:20 Company: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkglarea.c#L425 goes through all the GL texids in its pool and picks the first free one
11:20 Company: so all in all, pretty much like you'd do wl_buffer, too
11:22 Company: only that GdkTexture is what pq refered to as wl_locked_buffer
11:23 pq: this discussion makes me want to go write stuff in Rust :-)
11:24 Company: I don't think Rust makes this any more obvious
11:25 Company: but I don't write Rust, so I might be very wrong
11:26 Company: but I don't see where it gets you the lock/unlock step unless you put it there yourself
11:26 pq: much of the Rust patterns applicable here would also be doable in C, like different types for locked and unlocked buffers.
11:26 Company: yeah
11:27 pq: "destroy" the old type object, don't leave it lingering, and offer no other way
11:28 Company: and the only way to get the old object back is via the last unlock - though you need a callback for that because you don't know who's unlocking it last
11:29 pq: is there a reason to allow multiple readers though?
11:29 Company: yes, absolutely
11:30 Company: i mean, there's simple things like icons
11:30 Company: that get used in multiple places
11:30 pq: okay, but will those ever get re-written too?
11:31 Company: no, probably not
11:31 Company: but it's the same kind of object: a bunch of pixels used as a source
11:32 Company: we use GdkTexture for everything, from icon to 4k video
11:32 pq: another type: permanently locked, which allows making more permanently locked objects referring to the same storage.
11:32 Company: we don't do that, but you could
11:33 Company: we have a different layer for using parts of storage - that's a rendering/clipping task
11:34 pq: then you also need strong hygiene to never store a pointer to the same object in two places - Rust's borrow checker enforeces that, but in C it's manual.
11:34 Company: that's the typical refcounting game you have everywhere in Gnome
11:34 Company: if you store the pointer, take a reference
11:34 pq: no ref counting
11:35 pq: you just don't hold it in more than one place.
11:35 pq: or maybe you assert that the ref count never exceds 1
11:35 Company: that can work, but might not
11:35 Company: I mean, you can always wrap it in a shared_ptr
11:36 pq: yeah, that's the weak point, keeping the hygiene
11:36 pq: no, that would be bad
11:36 pq: that's the thing one must not do, for the type system to work
11:36 pq: in C
11:37 pq: or did you mean for enforcing the ref count never exceeds 1?
11:38 Company: I meant for allowing more than 1 place to refer to it
11:38 pq: ok, that would be bad.
11:39 pq: if multiple places needed a locked buffer, each place would need to own its own locked buffer object, and those can refer to the same storage only if they are permanently locked buffers, because any other kind of buffer reference/object has no way to make a duplicate.
11:41 pq: That's the kind of pattern that playing with Rust has given me.
11:43 Company: you can make the locking its own object, I see no reason to not design it that way
11:43 pq: hm?
11:43 Company: but when all the locks are unlocked again, you want the storage to be reusable
11:44 pq: that complicates the design, I'm assuming that's not needed
11:44 Company: if it's not needed then the thing is always locked anyway
11:44 Company: and there's not even a way to modify it
11:45 Company: so there's no need to lock it
11:45 pq: needs a callback of sorts, like you said, and that's not quite a type system anymore
11:46 pq: the point of locking is to be able to unlock; the point of locking permanently is to be able to allow multiple readers
12:57 dj-death: sima: yeah it does
12:57 dj-death: sima: I was talking about other buffers in Anv
12:58 dj-death: I guess it's possible to do for all buffers in Iris
12:58 sima: ah yeah anv only needs to do this for winsys and not for anything else
12:58 dj-death: because we track all buffers
12:58 dj-death: referenced in a batch
12:58 dj-death: but the bindless nature of vulkan makes it a lot more tricky to do
14:16 demarchi: MrCooper: IMO it shouldn't be a option to each user to decide if mailman will mangle the email for everybody. It doesn't help that that is the default value and few people understand the issue to go and change
14:17 demarchi: MrCooper: not mangling the Cc and just applying the same logic based on user selection would be acceptable though
14:18 emersion: yeah, mailman has too many knobs
14:45 daniels: the kernel.org archiver doesn't have nodupes enabled, so it shouldn't be seeing cc mangling
14:46 daniels: err, I think 'not metoo' might be the relevant option, but it's still not enabled
15:17 MrCooper: demarchi: the option affects only the subscribers which enable it, not anybody else
15:21 demarchi: MrCooper: that's not true... the header is changed so if I Cc both dri-devel and intel-linux, someone *else* subscribed to both will get 2 different emails with a different set of Cc.
15:23 MrCooper: only if that someone else enabled the option
15:24 demarchi: no... that someone could be someone external to the mailing list (like lore.kernel.org is)
15:26 MrCooper: not following, how would they get 2 e-mails with different Cc then?
15:29 MrCooper: nvm, I remembered now, it does actually drop the subscribers from Cc even in the e-mails sent to other subscribers :(
15:30 MrCooper: gotta be one of the worst mis-features ever
15:35 MrCooper: daniels: it is "Avoid duplicate copies of messages?", not "Receive your own posts to the list?"
15:36 daniels: the archiver doesn't have either enabled tho
15:36 daniels: well, it doesn't have 'nodupes' nor 'not metoo' enabled
15:36 daniels: it sounds like 'Receive your own posts to the list' is !(not metoo)
15:38 MrCooper: indeed it does
15:40 MrCooper: anyway, unfortunately it doesn't matter that the archiver doesn't enable it, mailman drops any subscriber address which enabled the option from Cc in any e-mail it sends out to any subscriber
15:41 MrCooper: so if that option could be globally disabled, that might eliminate one reason for the trouble with gmail
15:42 pq: Then there are people who get really upset if someone Cc's them while they also get the mail via a list. Then they scream at the sender.
15:43 daniels: email: not even once
15:45 pq: which setting exactly are you talking about?
15:46 MrCooper: pq: that would be addressed by just not sending list posts to subscribers in Cc, which is what the option description talks about; the problem is that it also mangles the posts sent to other subscribers (which isn't clearly documented)
15:46 daniels: https://lists.freedesktop.org/mailman/options/wayland-devel
15:46 daniels: except for dri-devel
15:46 daniels: one of those is 'Receive your own posts to the list?' and one of those is 'Avoid duplicate copies of messages?'
15:48 pq: MrCooper, aha, that explains, because the "Avoid duplicate..." option sounded like it should do the right thing.
15:48 MrCooper: yeah, it's a fine trap
15:48 pq: and I've set it to "yes" on every list
15:50 demarchi: MrCooper: yeah... not sending the email should be fine, but we shouldn't mangle the email being delivered
15:56 daniels: we should be using mailing-list software that doesn't require python 2
15:56 dj-death: gfxstrand: would you have any input on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23523/diffs?commit_id=8233e2d08c161bdcf3d71a00b5442be170b99409 ?
15:57 dj-death: gfxstrand: since we're talking about layering on mesa-dev ;)
15:57 gfxstrand: hehe
15:58 gfxstrand: dj-death: This is an example of the layering issues we're running into. :sob:
15:59 dj-death: gfxstrand: yeah, I have an email written about this, but I don't think it's contributing anything to the discussion so... probably will not send it ;)
16:02 gfxstrand: dj-death: I mean, feel free. I value your thoughts as much as anyone else who's chimed in.
16:44 dj-death: gfxstrand: for what it's worth I thought that shitting toward internal interfaces would be better
16:44 dj-death: gfxstrand: in that case we could have internal types of barriers
16:44 gfxstrand: Yup
16:44 gfxstrand: That's kind-of my plan
16:45 dj-death: gfxstrand: and also have the metadata on the attachments to better deal with those types of cases
16:45 gfxstrand: Just eat the duplication and add some python if it helps
16:45 gfxstrand: Then we can modify stuff at will
16:45 dj-death: did I write shitting
16:45 dj-death: I meant shifting
16:45 dj-death: obvisouly :)
16:45 gfxstrand: I mean, you can shit towards internal interfaces if you want. (-:
16:46 dj-death: heh
17:16 jenatali: The Vulkan CTS doesn't have any shaders that do aliasing of SSBOs/UBOs :(
17:16 gfxstrand: Oh?
17:16 jenatali: > There are no limits on the number of shader variables that can have overlapping set and binding values in a shader
17:16 jenatali: Dozen definitely doesn't handle that
17:21 gfxstrand: woof
17:21 jenatali: Woof indeed
17:38 dj-death: can you access both at the same time though?
17:39 dj-death: probably not?
17:39 jenatali: > If multiple shader variables are declared with the same set and binding values, and with the same underlying descriptor type, they can all be statically used within the same shader.
17:40 jenatali: https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap15.html#interfaces-resources-setandbinding in the "Note" block
17:40 dj-death: same descriptor type okay
17:41 dj-death: but both ssbo & ubo
17:41 jenatali: Yeah that's invalid
17:41 jenatali: I just don't handle 2 SSBOs with the same binding right now
17:49 dj-death: gfxstrand: so I take it you don't oppose my runtime change?
17:50 gfxstrand: dj-death: No, I don't
17:50 gfxstrand: dj-death: Oh, I did have a comment, though.
17:55 demarchi: daniels: that would be a good, but it would be hard to transition to something else, no?
17:56 dj-death: gfxstrand: thanks a lot, will do
18:01 daniels: demarchi: yes