mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #dri-devel
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #dri-devel
sassefa has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
arkfuture_ has quit [Remote host closed the connection]
arkfuture_ has joined #dri-devel
mrkajetanp has quit [Max SendQ exceeded]
mrkajetanp has joined #dri-devel
flom84 has joined #dri-devel
flom84 has quit []
kts has joined #dri-devel
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #dri-devel
kts has quit []
mrkajetanp has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
heat has joined #dri-devel
gouchi has joined #dri-devel
mrkajetanp has joined #dri-devel
mrkajetanp has quit [Ping timeout: 480 seconds]
arkfuture_ has quit [Read error: Connection reset by peer]
coldfeet has quit [Remote host closed the connection]
kts has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
nerdopolis has joined #dri-devel
mrkajetanp has joined #dri-devel
mrkajetanp has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
kzd has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #dri-devel
mrkajetanp has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<MrCooper>
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"
mrkajetanp has joined #dri-devel
<Company>
that's not quite true
<Company>
OpenGL allows shooting oneself in the foot, too
<Company>
but Vulkan comes with footgun included and requires you to use it
mrkajetanp has quit [Ping timeout: 480 seconds]
<bluetail>
is Vulkan the "Rust" of C ?
<Ermine>
the what
<bluetail>
The holy grail for OpenGL
<bluetail>
instead of OpenGL, to use... no matter the technical difference of nature
<Ermine>
the opposite comparison is more true I'd say
<bluetail>
I remember some Vulkan promos where it just outperformed most of the time... Well I guess here goes another half-truth
<bluetail>
I know it inherently uses OpenGL
<bluetail>
But I guess it can't do magic
<Ermine>
It doesn't inherently use OpenGL
<bluetail>
Interesting
mrkajetanp has joined #dri-devel
<MrCooper>
Vulkan is lower level than OpenGL
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #dri-devel
<K900>
If you want a programming language comparison, Vulkan is to OpenGL what C is to Python
<K900>
(very, very roughly)
rasterman has quit [Quit: Gettin' stinky!]
<kisak>
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.
cr0n has quit []
<bluetail>
I love those replies. Thanks a lot!
<kisak>
Of course, OpenGL got polish over the years, but there's some core design choices from yesteryear that have realtime performance costs.
mrkajetanp has quit [Ping timeout: 480 seconds]
<bluetail>
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.
<bluetail>
I did do that because I wanted that fancy fps overlay called mangohud
<Ermine>
zinc implements opengl on top of vulkan. If your program uses vulkan, zinc is not used
<bluetail>
it was an old java game, using lwjgl 2.8.5
<kisak>
Mangohud can also be used with OpenGL.
<bluetail>
mangohud absolutely did not show up until I used zinc
<K900>
And I don't think old Java games generally do Vulkan
<K900>
And that usually means you were holding mangohud wrong
<K900>
It's harder to set up with OpenGL games
<bluetail>
I see
<bluetail>
I do not want to solve it. This was sorta rant
<Company>
Vulkan is faster than OpenGL if the developers know what they're doing
<Company>
if they don't, usually OpenGL will be faster - because it's more forgiving
cr0n has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
coldfeet has joined #dri-devel
<DemiMarie>
Company: I don't know what I am doing, so that means I will use OpenGL.
<Company>
I would very much suggest that, yes
kts has quit [Quit: Leaving]
<Company>
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
<Company>
and the good reason to not use Vulkan is (1) You need it to work.
<DemiMarie>
Should I fear OpenGL losing support in the future?
<K900>
Not really
<Ermine>
No
<Ermine>
Vulkan is not for everybody, so opengl is going to stay
<DemiMarie>
Is Vulkan mostly for middleware libraries that expose a higher-level API?
mrkajetanp has joined #dri-devel
<Ermine>
depends on the case I think?
<K900>
It's also for doing really high performance stuff which generally means videogames
<DemiMarie>
I thought OpenGL could not do color management.
<Ermine>
or GPGPU stuff
<K900>
But there's also compatibility layers for pretty much every high level render API in existence now that are built on top of Vulkan
<K900>
Zink for OpenGL, DXVK/VKD3D for Direct3D
<K900>
OpenGL can do color management kinda
<DemiMarie>
Kinda?
<K900>
Kinda as in it's an extension and not all drivers implement it
<K900>
But I guess that's not really any worse than the Vulkan situation
colinmarc has joined #dri-devel
mrkajetanp has quit [Ping timeout: 480 seconds]
<Company>
DemiMarie: color management is outside the scope of GL/Vulkan really
<Company>
it needs to be done in the platform layer - which in GL is really different, ie EGL for Wayland or WGL for Windows
* DemiMarie
wishes that she could copy to CPU buffers in the guest, since those are super simple.
gouchi has quit [Remote host closed the connection]
<Company>
in Vulkan it's done via extensions that are part of the spec-with-extensions
<Company>
but that stuff isn't really what either GL or Vulkan are about
mrkajetanp has joined #dri-devel
kts has joined #dri-devel
<DemiMarie>
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?
<Company>
that depends what you mean by "stalled"
<Company>
but most likely the answer is "that's not a GL/Vulkan problem"
davispuh has joined #dri-devel
<DemiMarie>
It's a compositor problem, and OpenGL and Vulkan are the tools it has to work with.
<Company>
Vulkan/GL are C API definitions for an interface that can be used to draw stuff
<Company>
if you want to control hardware, you talk to the kernel
<K900>
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
<K900>
So on recent enough kernels/drivers you should be able to not have that problem ever
<Ermine>
A.k.a explicit sync? Or is this something else?
<K900>
Yes
<DemiMarie>
Company: And only OpenGL and Vulkan implementations know how to talk to the kernel.
<Ermine>
you can use libdrm directly...
<DemiMarie>
Does OpenGL support explicit sync?
<DemiMarie>
Ermine: yes, but I have no idea what parameters to fill in for things like GPU instructions.
<K900>
libdrm doesn't do GPU instructions really
<DemiMarie>
Exactly!
<K900>
Are you actually writing a compositor?
<DemiMarie>
Sort of
<DemiMarie>
I'm writing a pair of proxies
<K900>
If you are, you might want to use something like wlroots that handles most of this for you
<DemiMarie>
wlroots has too much attack surface
<K900>
wlroots might also be the wrong tool
<K900>
What are you actually trying to build?
mrkajetanp has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
<Company>
DemiMarie: every compositor talks to the kernel
Lucretia has quit [Remote host closed the connection]
<DemiMarie>
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.
<DemiMarie>
That will use wlroots because it is not a security boundary and wlroots knows how to do the job well.
<DemiMarie>
On the host, I have something that sanitizes the inputs from the guest and passes it to the real host compositor.
<DemiMarie>
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.
Schrostfutz has joined #dri-devel
<DemiMarie>
Also, I'm not sure if I want the Mesa user-mode driver to be in the guest-exposed attack surface.
<Company>
have you looked at how browsers handle WebGL?
<DemiMarie>
These problems can be solved by having the host compositor do a blit to buffers that it allocates.
<Company>
because that seems like a similar problem
<DemiMarie>
No, it is not.
<DemiMarie>
For one, the attack surface of WebGL is far too high.
<DemiMarie>
Secondly, I operate at a far lower level than WebGL.
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
<Company>
we were talking about rendering APIs more or less
mrkajetanp has joined #dri-devel
<Company>
and WebGL is a much simpler one than Vulkan/GL
LeviYun has quit [Ping timeout: 480 seconds]
<DemiMarie>
Is there a WebGL implementation that allows importing dmabufs?
<K900>
Company: No you're not?
<DemiMarie>
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.
<DemiMarie>
So the guest would only be hurting itself, which is allowed.
<Company>
I would expect every WebGL implementation to import dmabufs
<DemiMarie>
Company: where?
<Company>
I know that in epiphany the sandboxed we process sends dmabufs to the UI process
<DemiMarie>
Company: interesting!
<Company>
I mean, the web process needs to create a backbuffer for the webpage using WebGL
<Company>
and it needs to get that backbuffer to the screen somehow
<DemiMarie>
In Firefox and Chrome there is a separate GPU process, but it is global, which is worse.
<Company>
which ultimately means it's gonna travel as a dmabuf over Wayland
<DemiMarie>
That's export only, or did I make a mistake?
<Company>
somebody is gonna import it
<DemiMarie>
Compositor
<Company>
right
<Company>
so that's worse than your idea
mrkajetanp has quit [Ping timeout: 480 seconds]
<DemiMarie>
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?
<Company>
there is no database that I know of
dsimic is now known as Guest2897
dsimic has joined #dri-devel
<DemiMarie>
😞
<Company>
I treat dmabufs as a black box and hand all the fds and the attributes from one side to the other
<Company>
and just hope it works
LeviYun has joined #dri-devel
Guest2897 has quit [Ping timeout: 480 seconds]
<DemiMarie>
That works so long as one trusts Mesa to properly validate parameters.
<Company>
if it doesn't, I can just file a bug and wait for it to get fixed
<Company>
because my code is not a security boundary :)
<DemiMarie>
The parts dealing with sandboxed WebKitGTK+ renderers are, if you do that.
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<Company>
that's the job of webkit-gtk, not mine
<DemiMarie>
Fair
<DemiMarie>
Is it okay for me to enable desktop OpenGL instead of OpenGL ES?
<Company>
GTK uses GLES beccause it (a) has some extensions that GL proper doesn't have and (b) has less undefined behavior
<DemiMarie>
Does it have weaker or stronger guarantees around robust access.
<DemiMarie>
?
<Company>
no idea, I've not looked at that
<Company>
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
<DemiMarie>
Do you use robust access?
yyds has quit [Remote host closed the connection]
<DemiMarie>
Anyway this is getting offtopic.
<Company>
I don't think we enable it, but I'd have to check
<DemiMarie>
Conclusion: I will use OpenGL (probably ES) on the host, and whatever wlroots does in the guest.
LeviYun has joined #dri-devel
<Company>
i'd try to write code against GLES, usually that makes it portable to GL proper
<Company>
not necessarily the other way
<Company>
or said differently: it's way easier to port from GLES to GL than from GL to GLES
Company has quit [Quit: Leaving]
mrkajetanp has joined #dri-devel
Duke`` has joined #dri-devel
edolnx_ has joined #dri-devel
edolnx__ has joined #dri-devel
mrkajetanp has quit [Ping timeout: 480 seconds]
edolnx___ has joined #dri-devel
edolnx____ has joined #dri-devel
edolnx has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
edolnx_ has quit [Ping timeout: 480 seconds]
Simonx22_ has quit []
LeviYun has quit [Ping timeout: 480 seconds]
Simonx22 has joined #dri-devel
edolnx__ has quit [Ping timeout: 480 seconds]
edolnx___ has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #dri-devel
edolnx has joined #dri-devel
LeviYun has joined #dri-devel
mrkajetanp has quit [Ping timeout: 480 seconds]
edolnx____ has quit [Ping timeout: 480 seconds]
edolnx_ has joined #dri-devel
edolnx__ has joined #dri-devel
edolnx has quit [Ping timeout: 480 seconds]
edolnx_ has quit [Ping timeout: 480 seconds]
edolnx has joined #dri-devel
edolnx__ has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #dri-devel
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #dri-devel
nerdopolis has joined #dri-devel
edolnx_ has joined #dri-devel
rasterman has joined #dri-devel
edolnx has quit [Ping timeout: 480 seconds]
Lucretia has joined #dri-devel
Lucretia has quit [Remote host closed the connection]
Lucretia has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
edolnx has joined #dri-devel
edolnx_ has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
Schrostfutz has quit [Remote host closed the connection]
Schrostfutz has joined #dri-devel
Sachiel has joined #dri-devel
mrkajetanp has joined #dri-devel
mrkajetanp has quit [Ping timeout: 480 seconds]
Schrostfutz has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #dri-devel
frankbinns1 has joined #dri-devel
LeviYun has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
gouchi has joined #dri-devel
ManMower has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Lucretia has quit [Remote host closed the connection]
mrkajetanp has joined #dri-devel
mrkajetanp has quit [Ping timeout: 480 seconds]
edolnx_ has joined #dri-devel
edolnx has quit [Ping timeout: 480 seconds]
<Lynne>
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
<Lynne>
vkGetDescriptorSetLayoutSize vs vkDescriptorSetLayoutSizeGet
balrog_ has joined #dri-devel
balrog has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
mrkajetanp has joined #dri-devel
kts has quit [Quit: Leaving]
LeviYun has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
vliaskov__ has joined #dri-devel
vliaskov__ has quit [Remote host closed the connection]
vliaskov__ has joined #dri-devel
LeviYun has joined #dri-devel
acryo has joined #dri-devel
alanc has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
alanc has joined #dri-devel
vliaskov_ has joined #dri-devel
mrkajetanp has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
vliaskov__ has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #dri-devel
LeviYun has joined #dri-devel
mrkajetanp has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]