<eric_engestrom>
zmike: sorry, I really don't know piglit's core code, can't review that :(
<eric_engestrom>
soreau: (late reply to your question on friday about mesa!31725) I think daniels/zmike/ajax would be my go-to for dri+modifiers reviews
Guest6987 has quit [Read error: Connection reset by peer]
servik has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Quit: Leaving.]
cmichael has quit [Quit: Leaving]
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
tzimmermann has quit [Quit: Leaving]
tobiasjakobi has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
epoch101_ has quit []
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
fahien has quit [Ping timeout: 480 seconds]
epoch101 has quit []
kts has quit [Quit: Leaving]
epoch101 has joined #dri-devel
epoch101 has quit []
LeviYun has quit [Ping timeout: 480 seconds]
krushia has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
krushia has joined #dri-devel
epoch101 has joined #dri-devel
epoch101 has quit []
nvishwa1_ has joined #dri-devel
fahien has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
fahien has quit [Ping timeout: 480 seconds]
nvishwa1_ has quit [Remote host closed the connection]
phire_ has joined #dri-devel
phire is now known as Guest6992
phire_ is now known as phire
Guest6992 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
fab has joined #dri-devel
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
tobiasjakobi has quit []
epoch101 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
himal has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
fahien has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
warpme has quit []
fahien has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
fahien has joined #dri-devel
gouchi has joined #dri-devel
epoch101 has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
Lucretia has quit [Remote host closed the connection]
crabbedhaloablut has quit []
Lucretia has joined #dri-devel
crabbedhaloablut has joined #dri-devel
RSpliet has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 480 seconds]
RSpliet has joined #dri-devel
Haaninjo has joined #dri-devel
jsa has joined #dri-devel
epoch101 has quit []
coldfeet has joined #dri-devel
epoch101 has joined #dri-devel
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
fahien has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
gouchi has quit [Quit: Quitte]
epoch101 has quit []
epoch101 has joined #dri-devel
epoch101 has quit []
jsa has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
<Company>
jenatali: Can I pick your brain a bit about GTK on Windows?
<jenatali>
Sure?
<Company>
GTK is a GL or Vulkan app
<Company>
on Wayland that is great, on Windows it's not
<Company>
because Windows is all about DirectX
crabbedhaloablut has quit []
<jenatali>
I mean, Windows supports GL and VK
<Company>
also, because GL/Vulkan on WIndows are optimized around opaque fullscreen stuff and not about desktop apps
<Company>
and I'd like to figure out how to get us closer to rendering on Windows
<jenatali>
So what's the problem?
crabbedhaloablut has joined #dri-devel
<Company>
the first thing is that I don't understand how compositing works on Windows
<DemiMarie>
Company: Can you use Mesa's Dozen?
<Company>
like, I need to enable GDI to get transparency support?
<Ermine>
ship with mesa's vk driver *ducks*
<jenatali>
Ah, yeah ok I see the problem
<DemiMarie>
jenatali: What would it take for Dozen to reach Vulkan 1.3 + enough extensions for OpenGL 4.6 via Zink?
<jenatali>
Demi: A lot
<Company>
there's also lots of stuff on Google about take DXGISwapChains and using EXT_external_objects to import them as backbuffer into GL
<jenatali>
Okay well probably not too much to get close, but there's at least one minor feature in 1.3 that D3D doesn't spec, which is that memory footprint for textures must strictly decrease as the texture size decreases
<jenatali>
Company: So fundamentally, Windows has 2 compositing models, similar to Linux. GDI is like X, there's a single global render order and compositing is done "as if" you were drawing to the screen, for the most part
<jenatali>
And then there's the DWM (desktop window manager) and DComp (Direct Composition), which look like Wayland, and let you take advantage of the fact that the desktop is actually retained these days
<Company>
should I think about DComp stuff as running in the compositor or in the client?
<jenatali>
Fundamentally the problematic difference for you is that GL and VK drivers (typically) interact with the graphics kernel directly, through the publicly documented WDDM interface. D3D drivers interact with that through an abstraction on top of that interface, which lets D3D fill in some pieces
<jenatali>
DComp has client APIs that let you tell the compositor what to do
sima has quit [Ping timeout: 480 seconds]
<jenatali>
For shared resources, specifically, GL/VK can open resources that D3D creates, but not the other way around. A GL/VK driver can open a resource because they see driver-specific data that the same driver stack wrote in another process. But for D3D to open a resource, it needs not just driver-specific data, but D3D-specific data
<Company>
so I build a compositing graph of sorts and the compositor composites it - with a more powerful API than wl_surface + wp_viewport + whatever
<jenatali>
And since the compositor runs on D3D, it can only open resources that D3D creates
<jenatali>
Company: Correct
danylo1 has joined #dri-devel
<jenatali>
So for GL/Vk, their present model is that they open GDI surfaces in the client process and blit into them. For DComp, the model is that the client allocates and shares it to the compositor
<jenatali>
Things like alpha transparency in GDI is... ugly. It's nicer in DComp but that does require having a D3D step in the way
<Company>
I suppose what the drivers do depends on the flags you set when creating the swapchain?
<Company>
and the features of the driver itself?
<Company>
or when setting the pixelformat in WGL
<jenatali>
It's more that on Windows, unlike Linux dmabufs which are just memory, shared resources marshal all of the metadata of creation properties (like format, width, height, pitch) along with the shared handle
<DemiMarie>
jenatali: Is Dozen a solution to this problem?
<jenatali>
So for D3D to figure out WTF you opened, it needs to have it in a D3D-understood format
<Company>
right
<jenatali>
Demi: Yes, Dozen uses a DXGI/DComp swapchain
<Company>
so I would probably want to do some DComp setup inside GTK
<DemiMarie>
jenatali: Do all of the major IHVs provide GL and Vulkan drivers on Windows?
<Company>
and then let Vulkan/GL render into some offscreen and composite that
<Company>
DemiMarie: yes, but lots of them target games
<jenatali>
Demi: 3/4 IHVs provide GL (QC uses GLOn12). All 4 currently provide Vk, though QC only started with their latest iteration (Snapdragon X). Older QC generations require Dozen
<Company>
jenatali: one thing I wondered while reading through this stuff - has there ever been talk about vkSwapChainCreateFromDXGISwapchain or some integration between the two?
fahien has joined #dri-devel
<jenatali>
GLOn12 is often more performant than the native GL drivers on Windows though...
<Company>
and make the equivalent of our DmabufTexture be a D3D12ResourceTexture
<Company>
and then all I need to do is find a gsoc student to write a D3D renderer
<jenatali>
EXT_external_object is tricky to get right. If you're directly sharing a D3D swapchain buffer, D3D needs to be the first writer into the resource every frame, otherwise you miss inserting the implicit sync 🤢 that prevents the GL/Vk writer from overwriting the surface while the compositor is reading from it
<jenatali>
That sync is inserted by a special case in D3D when it detects a write. Which is why D3D12 doesn't allow UAV (storage image) to swapchain back buffers, because it's not detectable
fahien has quit [Ping timeout: 480 seconds]
<jenatali>
The comp swapchain I linked doesn't have that egregious design flaw...
<jenatali>
But, assuming you do that, then probably the sharing approach would be better
<Company>
that sounds like the solution is to go with the child HWND first
crabbedhaloablut has joined #dri-devel
<Company>
and then add the comp swapchain as an optimization for when the right features are supported
<DemiMarie>
Company: which features?
<Company>
I can figure that out when I get there :)
<Company>
jenatali: how do I solve the opacity problem?
<jenatali>
Honestly I dunno
<jenatali>
I work on D3D, I'm only familiar with windowing systems as far as it interacts there
<jenatali>
The D3D team also owned DXGI at some point in the past but we've never owned DComp, that's the compositor team
<Company>
for all I care, you work on Mesa, so you're paid to know about GL and Vulkan :p
<jenatali>
Sure, the D3D team also owns the GL/VK integration into Windows
<DemiMarie>
Company: is D3D an option?
<jenatali>
Feel free to embed a static link of GLOn12 or ANGLE if you want
<Company>
jenatali: doesn't D3D do transparency?
epoch101 has quit []
epoch101 has joined #dri-devel
<jenatali>
D3D only goes as far as rendering an alpha channel into a texture. How that gets interpreted by the compositor is something else
<jenatali>
And then you have to deal with things like hit-testing
<Company>
hit-testing is an entirely different task in GTK luckily for me
<Company>
and also not really that relevant because nobody cares outside of maybe rounded corners
<DemiMarie>
Ugh, rounded corners!
<Company>
so my problem with Vulkan/GL and transparency is that they talk to WDDM and not to DComp - or rather, they don't allow me to influence how they talk to DComp and say "I would like transparency plz"
epoch101 has quit []
epoch101 has joined #dri-devel
<jenatali>
Moreso that they only know how to interact with GDI and not DComp, and getting GDI transparency is complicated
<Company>
because my AMD driver only gives me VK_FORMAT_R8G8B8A8_UNORM but only COMPOSITE_ALPHA_OPAQUE_BIT_KHR
<jenatali>
I think. Idk I haven't tried
fahien has joined #dri-devel
<Company>
that was helpful
<Company>
thx
<jenatali>
Glad I could help
epoch101 has quit []
epoch101 has joined #dri-devel
sassefa has joined #dri-devel
<DemiMarie>
Company: Is putting a D3D layer in between an option?
<Company>
DemiMarie: the problem with D3D is that somebody needs to write that code
<DemiMarie>
jenatali: What do you think about having Mesa someday be the official UMD for Windows?
<DemiMarie>
Company: you?
<jenatali>
It's not up to me
<Company>
if I had a D3D renderer, I'd just use it - but I don't (yet?)
<jenatali>
By which I mean, it's not up to us. We're not in the business of shipping drivers
<jenatali>
Company: You can ship a GL->D3D layer?
fahien has quit [Ping timeout: 480 seconds]
<Company>
yeah, that's an option
<DemiMarie>
jenatali: GTK is moving to Vulkan.
<jenatali>
So ship dzn?
<jenatali>
It's all open source so it can be embedded if you want
<DemiMarie>
(which reminds me that using Vulkan will e-waste some Arm boards that have hardware GL but only software VK)
<Company>
GTK is supporting GL, GLES and Vulkan equally well atm
<DemiMarie>
Company: thanks for the correction
<DemiMarie>
Company: I was thinking of using D3D for a blit
<Company>
us using Vulkan is mostly because people here thought that's the best default
<DemiMarie>
Or rather having D3D create the resource and VK render into it.
<jenatali>
I wouldn't complain about having a customer that might actually contribute improvements instead of just bug reports :P
epoch101 has quit []
<Company>
jenatali: the GTK Windows code is in pretty rough state
kasper93_ has joined #dri-devel
<Company>
jenatali: most of our apps are Linux only (or if they ship on Windows they care very little) and the 2 big ones - Inkscape and Gimp - were stuck on GTK2 for too long which made the Windows thing deteriorate
<Company>
plus we used autotools and autotools and Windows don't mix
<jenatali>
Ah yeah
<jenatali>
I'm glad we started working with Mesa after the meson switch
<Company>
I just decided this month to look at it again with meson's VSCode integration work, and I am pleasantly surprised
<Company>
I think I can develop from inside VSCode
<Company>
jenatali: how do you actually develop?
<Company>
Mesa uses meson, too, after all
<jenatali>
Meson to generate a VS project
kasper93 has quit [Ping timeout: 480 seconds]
<Company>
and then when you do build system stuff you regenerate that VS project after every change?
* DemiMarie
hopes autotools is officially deprecated
<jenatali>
Yeah, it's pretty quick
<DemiMarie>
Ideally the VS project could regenerate itself as needed.
<Company>
I should try VS
<jenatali>
Demi: It does
<Company>
it apparently has better debugging stuff - like an actual profiler
<jenatali>
Indeed
<DemiMarie>
jenatali: does it happen automatically if the Meson files are changed?
* DemiMarie
has not profiled in years
<jenatali>
Yes
<DemiMarie>
nice
sassefa has quit []
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
<DemiMarie>
Company: how much of GTK’s performance issues are uniformly slow code due to too much pointer chasing?
<Company>
first we have to define what we mean with "GTK's performance issues"
<DemiMarie>
you mentioned profiling, so I assumed you are interested in performance work
<Company>
yeah, but that's mostly stuff like figuring out if the Windows backend code does something dumb
<Company>
like using GDI when it should use DComp
<DemiMarie>
I see. I was wondering if GObject is itself a major performance problem for GTK.
<Company>
again, depends
<Company>
I think GObject is much worse in terms of lacking modern language features that developers want who use bindings
<Company>
GObject itself doesn't do very much
<Company>
that's not quite true, but the way it's mainly used these days as an RTTI system, it isn't quite performance relevant
<Company>
the problems with GObject happen when people use RAD stuff, because then the marshaling overhead can make things slow
<DemiMarie>
Marshaling overhead?
<Company>
when you use xml to bind your application state to GTK widget properties and have them update once per frame
<Company>
for 100s or 1000s of widgets
<Company>
like After Effects for example
YuGiOhJCJ has joined #dri-devel
docmax__ has joined #dri-devel
<Company>
DemiMarie: the biggest problems with GTK in terms of performance is that computers are so fast that nobody needs to care about it and then developers get hit with them using O(N^2) alogithms once somebody adds lots of whatever in their apps and get really surprised