12:39MrCooper: DemiMarie: one big difference between OpenGL and Vulkan: with OpenGL, it's the driver's responsibility not to program the HW improperly, even if the application doesn't use the GL API correctly; whereas with Vulkan, things like GPU hangs can be the expected result if the application "holds it wrong"
12:49Company: that's not quite true
12:49Company: OpenGL allows shooting oneself in the foot, too
12:50Company: but Vulkan comes with footgun included and requires you to use it
12:55bluetail: is Vulkan the "Rust" of C ?
12:55Ermine: the what
12:55bluetail: The holy grail for OpenGL
12:56bluetail: instead of OpenGL, to use... no matter the technical difference of nature
12:56Ermine: the opposite comparison is more true I'd say
12:57bluetail: I remember some Vulkan promos where it just outperformed most of the time... Well I guess here goes another half-truth
12:57bluetail: I know it inherently uses OpenGL
12:57bluetail: But I guess it can't do magic
12:58Ermine: It doesn't inherently use OpenGL
13:02bluetail: Interesting
13:04MrCooper: Vulkan is lower level than OpenGL
13:12K900: If you want a programming language comparison, Vulkan is to OpenGL what C is to Python
13:12K900: (very, very roughly)
13:14kisak: There's about 25 years separating when a group of devs sat down to design OpenGL and Vulkan. In those decades, how the video acceleration hardware works in today's generation isn't particularly close to how we thought it would become decades ago and Vulkan closer matches how hardware is designed today.
13:15bluetail: I love those replies. Thanks a lot!
13:15kisak: Of course, OpenGL got polish over the years, but there's some core design choices from yesteryear that have realtime performance costs.
13:19bluetail: when I enforce java to use Vulkan and not its old legacy OpenGL interface, it gets slower in this case. I think it was some variable with zinc or something.
13:20bluetail: I did do that because I wanted that fancy fps overlay called mangohud
13:21Ermine: zinc implements opengl on top of vulkan. If your program uses vulkan, zinc is not used
13:21bluetail: it was an old java game, using lwjgl 2.8.5
13:21kisak: Mangohud can also be used with OpenGL.
13:22bluetail: mangohud absolutely did not show up until I used zinc
13:22K900: And I don't think old Java games generally do Vulkan
13:22K900: And that usually means you were holding mangohud wrong
13:22K900: It's harder to set up with OpenGL games
13:22bluetail: I see
13:23bluetail: I do not want to solve it. This was sorta rant
13:23Company: Vulkan is faster than OpenGL if the developers know what they're doing
13:24Company: if they don't, usually OpenGL will be faster - because it's more forgiving
13:36DemiMarie: Company: I don't know what I am doing, so that means I will use OpenGL.
13:36Company: I would very much suggest that, yes
13:39Company: the good reasons to use Vulkan IMO are (1) you want to learn how GPUs work and have time, (2) you care about the future more than the present, (3) you absolutely need the performance and control Vulkan gives you
13:40Company: and the good reason to not use Vulkan is (1) You need it to work.
13:43DemiMarie: Should I fear OpenGL losing support in the future?
13:44K900: Not really
13:44Ermine: No
13:44Ermine: Vulkan is not for everybody, so opengl is going to stay
13:45DemiMarie: Is Vulkan mostly for middleware libraries that expose a higher-level API?
13:45Ermine: depends on the case I think?
13:45K900: It's also for doing really high performance stuff which generally means videogames
13:46DemiMarie: I thought OpenGL could not do color management.
13:46Ermine: or GPGPU stuff
13:46K900: But there's also compatibility layers for pretty much every high level render API in existence now that are built on top of Vulkan
13:46K900: Zink for OpenGL, DXVK/VKD3D for Direct3D
13:47K900: OpenGL can do color management kinda
13:47DemiMarie: Kinda?
13:48K900: Kinda as in it's an extension and not all drivers implement it
13:48K900: But I guess that's not really any worse than the Vulkan situation
14:00Company: DemiMarie: color management is outside the scope of GL/Vulkan really
14:01Company: it needs to be done in the platform layer - which in GL is really different, ie EGL for Wayland or WGL for Windows
14:01DemiMarie:wishes that she could copy to CPU buffers in the guest, since those are super simple.
14:01Company: in Vulkan it's done via extensions that are part of the spec-with-extensions
14:02Company: but that stuff isn't really what either GL or Vulkan are about
14:06DemiMarie: Does OpenGL provide enough control for a compositor to not be stalled forever by a client that keeps rendering to the same buffer over and over?
14:08Company: that depends what you mean by "stalled"
14:08Company: but most likely the answer is "that's not a GL/Vulkan problem"
14:11DemiMarie: It's a compositor problem, and OpenGL and Vulkan are the tools it has to work with.
14:11Company: Vulkan/GL are C API definitions for an interface that can be used to draw stuff
14:12Company: if you want to control hardware, you talk to the kernel
14:13K900: It's not really a Vulkan/GL problem, it's kind of a DRM sync problem, and things are generally moving in the direction of external sync everywhere
14:13K900: So on recent enough kernels/drivers you should be able to not have that problem ever
14:13Ermine: A.k.a explicit sync? Or is this something else?
14:14K900: Yes
14:14DemiMarie: Company: And only OpenGL and Vulkan implementations know how to talk to the kernel.
14:15Ermine: you can use libdrm directly...
14:15DemiMarie: Does OpenGL support explicit sync?
14:16DemiMarie: Ermine: yes, but I have no idea what parameters to fill in for things like GPU instructions.
14:16K900: libdrm doesn't do GPU instructions really
14:16DemiMarie: Exactly!
14:16K900: Are you actually writing a compositor?
14:16DemiMarie: Sort of
14:16DemiMarie: I'm writing a pair of proxies
14:16K900: If you are, you might want to use something like wlroots that handles most of this for you
14:17DemiMarie: wlroots has too much attack surface
14:18K900: wlroots might also be the wrong tool
14:18K900: What are you actually trying to build?
14:20Company: DemiMarie: every compositor talks to the kernel
14:21DemiMarie: K900: In the guest, there will be a compositor that composites subsurfaces and speaks a subset of Wayland to the host over cross-domain virtio-GPU.
14:22DemiMarie: That will use wlroots because it is not a security boundary and wlroots knows how to do the job well.
14:23DemiMarie: On the host, I have something that sanitizes the inputs from the guest and passes it to the real host compositor.
14:24DemiMarie: Ideally, I would just sanitize guest buffers, but I was not able to figure out a way to validate guest dmabuf parameters without actually importing the buffer.
14:25DemiMarie: Also, I'm not sure if I want the Mesa user-mode driver to be in the guest-exposed attack surface.
14:26Company: have you looked at how browsers handle WebGL?
14:26DemiMarie: These problems can be solved by having the host compositor do a blit to buffers that it allocates.
14:27Company: because that seems like a similar problem
14:27DemiMarie: No, it is not.
14:27DemiMarie: For one, the attack surface of WebGL is far too high.
14:28DemiMarie: Secondly, I operate at a far lower level than WebGL.
14:29Company: we were talking about rendering APIs more or less
14:29Company: and WebGL is a much simpler one than Vulkan/GL
14:30DemiMarie: Is there a WebGL implementation that allows importing dmabufs?
14:31K900: Company: No you're not?
14:32DemiMarie: On further thought, I think I can trust wlroots in the guest to not try to stall the host proxy forever, because the consequences of such a stall are limited to in-guest denial of service. Other guests won’t be affected.
14:33DemiMarie: So the guest would only be hurting itself, which is allowed.
14:33Company: I would expect every WebGL implementation to import dmabufs
14:33DemiMarie: Company: where?
14:33Company: I know that in epiphany the sandboxed we process sends dmabufs to the UI process
14:34DemiMarie: Company: interesting!
14:34Company: I mean, the web process needs to create a backbuffer for the webpage using WebGL
14:35Company: and it needs to get that backbuffer to the screen somehow
14:35DemiMarie: In Firefox and Chrome there is a separate GPU process, but it is global, which is worse.
14:35Company: which ultimately means it's gonna travel as a dmabuf over Wayland
14:35DemiMarie: That's export only, or did I make a mistake?
14:36Company: somebody is gonna import it
14:36DemiMarie: Compositor
14:36Company: right
14:36Company: so that's worse than your idea
14:37DemiMarie: Is there a database of how to validate dmabuf params, like there is for shm buffers? Or is it the thousands of lines of code in Mesa?
14:38Company: there is no database that I know of
14:39DemiMarie: 😞
14:39Company: I treat dmabufs as a black box and hand all the fds and the attributes from one side to the other
14:39Company: and just hope it works
14:40DemiMarie: That works so long as one trusts Mesa to properly validate parameters.
14:41Company: if it doesn't, I can just file a bug and wait for it to get fixed
14:42Company: because my code is not a security boundary :)
14:45DemiMarie: The parts dealing with sandboxed WebKitGTK+ renderers are, if you do that.
14:50Company: that's the job of webkit-gtk, not mine
14:51DemiMarie: Fair
14:52DemiMarie: Is it okay for me to enable desktop OpenGL instead of OpenGL ES?
14:53Company: GTK uses GLES beccause it (a) has some extensions that GL proper doesn't have and (b) has less undefined behavior
14:53DemiMarie: Does it have weaker or stronger guarantees around robust access.
14:53DemiMarie: ?
14:54Company: no idea, I've not looked at that
14:55Company: mainly, GLES is better at defining how operations are performed, which ones have to be supported and which ones are optional and stuff like that
14:55DemiMarie: Do you use robust access?
14:56DemiMarie: Anyway this is getting offtopic.
14:56Company: I don't think we enable it, but I'd have to check
14:58DemiMarie: Conclusion: I will use OpenGL (probably ES) on the host, and whatever wlroots does in the guest.
15:00Company: i'd try to write code against GLES, usually that makes it portable to GL proper
15:00Company: not necessarily the other way
15:00Company: or said differently: it's way easier to port from GLES to GL than from GL to GLES
18:18Lynne: my third favorite aspect of the vulkan spec is how each function has reverse endianess so you cannot simply search for it in the spec
18:19Lynne: vkGetDescriptorSetLayoutSize vs vkDescriptorSetLayoutSizeGet