ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<gfxstrand>
I've got a pretty good stack of NVIDIA cards but my daily driver is still my trust XPS 13.
<gfxstrand>
I am a little annoyed at the lack of good NVIDIA laptops.
psykose has quit [Remote host closed the connection]
<Company>
I think gettng dual gpu laptops is probably a nice approach - because then people can fallback to intel and get work done if things are broken on nvidia somehow
<gfxstrand>
I had this fantastic 13 or 14-inch Razer a few years ago (had to give it back to Intel, sadly)
psykose has joined #dri-devel
<gfxstrand>
Hrm... Razer Blade 14 might not be a bad choice...
<gfxstrand>
It's NVIDIA+AMD not NVIDIA+Intel
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
ptrc has quit [Remote host closed the connection]
<Company>
that sounds like lots of fun with breakage can be had there
<gfxstrand>
TBH, having a laptop where I can hack on NVK and RADV at the same time doesn't sound like a bad thing.
ptrc has joined #dri-devel
<Company>
and you can fix all the dmabuf handoff problems between the 2 drivers
Kayden has quit [Quit: -> home]
<Company>
I have 2 AMDs in my desktop atm, but once I start playing my first UE5 game, I'll need a new GPU
<gfxstrand>
Company: I don't need to fix dma-buf handoff in order to run CTS tests. :P
<Company>
gonna do the gaming on Windows most likely, so the driver is not the issue, and AMD vs nvidia will be a question of what allows me the best experiments when developing
<Company>
I should learn to write CTS tests at some point
<Nefsen402>
I was recently shopping for a new laptop and ended up going with the questional decision of putting asahi linux on it. I already have a x86 desktop with 2x AMD gpus for dev anyway
<Company>
people using asahi have been very useful already and found some dumb issues with gnome's GLES usage
<Nefsen402>
Only super custom thing I did to it was patch sway to teach it about the notch with fullscreen stuff
<Company>
The high-level problem I have is still that application developers have no clue about GPUs
<Company>
everyone learned to work with Cairo, and Cairo is all CPU
<Nefsen402>
but bezier curves on the GPU is hard
<Company>
and when they use a GPU, they all have Intel, so the assumptions made about performance and whatnot are all learned from using that
<Company>
most importantly, the GPUs are all integrated, so people assume no memory transfer time
<Nefsen402>
rip wayland compositors that transfer shm textures while blocking the main thread...
<Company>
for example
<Company>
also, Intel laptops (at least pre-xe) are noticably slower when running shaders than dedicated GPUs
<Company>
but that's not even the bad thing
<Company>
the bad thing is when people assume every GPU supports the same formats Intel does
<Company>
or when nobody notices that the AMD cursor plane is scaled with the AMD primary plane because the Intel one isn't
<Company>
and stuff like that
<Company>
and the more people you have around that you can ask "hey can you test my branch works on your gpu", the better the code is gonna be and the less likely people are to misdesign stuff
<Company>
just assuming 1 plane for dmabufs, because it's always RGB anyway and that's just 1 plane, right?
<Company>
on Intel, it indeed is
<airlied>
gfxstrand: I don't think we need 1.3 to ship it, I'm pretty happy with the feature set we have right now
<airlied>
like yeah DXVK is the end goal, but I'm fine with that taking a bit longer
<Company>
do nvtop or radeontop work with nvk?
<airlied>
do they talk to vulkan drivers?
<airlied>
I'd have though they talked to the kernel
<Company>
I have no idea
<Company>
I just want an app that I can tell random developers to run so they can see if their app is CPU or GPU limited
<Company>
nvtop is a simple one, radeontop is a complicated but really useful one
<Company>
because nvtop doesn't show the GPU clock speed, and AMD is shown at ~70% no matter how much load there is
<airlied>
I think that would take some kernel development with GSP, I don't think we have any idea how to get access to stats yet
<Company>
would be nice to have a tool that worked with all gpus and that was commonly available
<Company>
but I guess that's not a new idea
idr has quit [Quit: Leaving]
<Company>
gfxstrand: looking through the mesamatrix, it says nvk doesn't do VK_KHR_incremental_present - is that an oversight somewhere?
<gfxstrand>
airlied: I'm less worried about feature set and more worried about general stability and how comfortable I am dealing with bug reports and backporting patches.
<gfxstrand>
Company: probably
<Company>
it's kinda important for desktop apps (that actually use Vulkan)
<airlied>
gfxstrand: not too worried about backporting patches, we can just roll fedora forward to the next release, I don't think we have anything that really depends on vulkan yet in the distro normal paths
pcercuei has quit [Quit: dodo]
<airlied>
like maybe someday gtk vulkan will get made the default
<gfxstrand>
airlied: Would you split NVK into a separate package or roll all of Mesa forward?
<airlied>
gfxstrand: we generally just roll all of mesa
<airlied>
it's something we do semi regularly
<gfxstrand>
kk
<airlied>
it hasn't really been that scary since we got CI
<airlied>
the odd WSI or someone tried to load zink automatically again and screwed up
<airlied>
I think it'll be scarier if we try and make zink the default GL for nvidia GPUs
<mareko>
DemiMarie: you can put Mesa into Android and then you can have virtio and native context
<Company>
airlied: the main reason I'd want to default Vulkan on GTK is because Mesa devs think it's a good idea
<gfxstrand>
It's probably a good idea on NVIDIA. :P
<airlied>
yeah I'd rather gtk used vulkan
<Company>
I'm not really into GTK being the one to find all the bugs with Vulkan unless I get buy-in into fixing things
<Company>
but the new renderer (once I land it, which should be before christmas) is definitely faster with Vulkan
<Company>
it doesn't integrate well with all the external GL stuff though
<Company>
and it suffers from Vulkan not doing dmabufs without modifiers
<Company>
and lots of places still handing out those things
<Company>
it also doesn't help us as long as gnome-shell still uses GL
flynnjiang has joined #dri-devel
<Company>
and gnome-shell has a much harder time converting to Vulkan, because they have infrastructure where they printf-build their shaders at runtime
<Company>
so they either need to include some glsl-to-spirv compiler or they need to refactor their code
<Company>
airlied: fwiw, my assumption so far was that RHEL10 was not interested in Vulkan - or even: interested in not Vulkan
<Company>
which is why I didn't prioritize a Vulkan transition very much
<Company>
and the 3 arguments for Vulkan in GTK could be RHEL10 wanting it, GPUs having better support for Vulkan over GL (and of the new drivers only nvk could qualify for that, asahi went GL first) or GTK having any needs
<Company>
and so far the only thing that Vulkan can do that GL can't - or at least not as well - is allocate dmabufs, but we don't need to do that yet in our API
Sachiel has quit [Read error: Connection reset by peer]
Sachiel has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
tristianc6704 has joined #dri-devel
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
luben has joined #dri-devel
illwieckz_ has joined #dri-devel
Kayden has joined #dri-devel
luben has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
<airlied>
Company: yeah gnome-shell would be a major amount of lift, esp with cogl and clutter in the mix
<Company>
it seems my secret plan to split the shell into compositor + panel processes and redoing the panel in GTK is still alive
<airlied>
yeah redoing all the clutter/cogl stuff in gtk4 would probably make life a lot easier
qwb has joined #dri-devel
<airlied>
though at what point a g-s reboot would have made sense before now I'm not sure :-P
qwb has quit []
jewins has joined #dri-devel
<Company>
I think it was a good idea to keep things separate
<Company>
GTK3 had a ton of limitations that the UI designs of the shell would have bumped again
<Company>
and I'm not sure that GTK4 is good enough for certain things that the shell does
<Company>
but things are converging - in terms of UI designs not being too different, in GTK gaining the interesting features and most importantly in developers talking more with each other
casif^ has quit [Remote host closed the connection]
cheako has joined #dri-devel
<Company>
up until 4.0.0 - and probably a while later - we were mostly concerned with API design and how applications want to use what we put out
<Company>
I've since pivoted towards working with the lower layers again to figure out new features we can expose to apps - like for example the dmabuf stuff
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<Company>
and people are learning that GTK is doing 100% of the rendering on the GPU, which is also interesting
<Company>
90%, we still render the glyphs masks with cairo
heat_ has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
<alyssa>
Company: fwiw i stand by my decision to go gl first, it was the right call afaict
<alyssa>
completely different set of constraints than nvk had
<Company>
why did you decide on GL?
<airlied>
GL is easier to get a driver started when you are RE'ing
<alyssa>
landscape 3 years ago when this started ... early r/e and needed something for r/e, easier to write a gallium driver than vk
<alyssa>
and then a year later .. wanted to get accellerated gnome/kde/etc into user hands asap, that was (is?) all gl
<alyssa>
(zink has improved a lot in 3 years, i'd also add.)
<Company>
would you decide differently today?
<alyssa>
Not sure.
<alyssa>
the other issue is... I know how to write gallium drivers, not yet vk drivers
<alyssa>
being able to ship competent gl very very fast was a sure thing for me
<alyssa>
being able to ship competent zink on vulkan... much less sure
<alyssa>
(similarly the vk runtime is a LOT better now than 3 years ago. thanks to gfxstrand's heroic nvk work)
<alyssa>
anyway, once all the hard problems are solved for gl, theoretically adding vk should be "easy"
<alyssa>
and then we'll have everything and yeah
<alyssa>
we're all going to the same place, just different order to get there
<Company>
and then you can delete the gl driver and switch to zink!
<alyssa>
probably not
<alyssa>
our gl driver is competent and takes advantage of hw that can't be exposed in vk
<alyssa>
i don't see any reason to drop it even if zink+agxv is at feature parity
<alyssa>
even for nvidia, writing a fresh gallium driver is very much in the cards
<alyssa>
^a possibility
<alyssa>
zink solves real problems
<alyssa>
it just doesn't solve any of mine right now
<Company>
zink is excellent at showing me I did something wrong, when the GL version of my renderer is faster with zink than my Vulkan version
<alyssa>
lol
<Company>
it's a really interesting comparison - native GL vs zink vs Vulkan
<Company>
it's how i figured out that Mesa is (was? I didn't check in a while) better at compiling GLSL than it is at compiling spirv
<Company>
but I take it that we've still not quite reached the point where Vulkan is preferred over GL - both on the app and the driver side
<Company>
any day now, but not yet
<airlied>
alyssa: what hw features are there not exposed btw?
psykose has quit [Remote host closed the connection]
illwieckz has joined #dri-devel
illwieckz_ has quit [Ping timeout: 480 seconds]
<mareko>
it would be difficult to outperform zink with vulkan API in some cases
<mareko>
where zink doesn't do well is when it needs to emulate something for Vulkan that the underlying hw can do
<mareko>
it's fixable
<mareko>
is zink+nvk faster than nvc0? or do they both target completely different hw?
<airlied>
I think nvc0 has a lot of problems, so I suspect zink will be faster
<airlied>
but once you add in having a competent compiler, I think saving nvc0 will be hard
<mareko>
I quite suspect the same thing
<airlied>
if I thought it was worth it I'd write a new gallium driver
<mareko>
zink also uses all of the multithreading in the common code that nvc0 doesn't
<mareko>
and other fast paths
<airlied>
I'd hate to try and enable any of that in nvc0
* airlied
is just trying to get zink/nvk closer to GL 4.6 conformant now
<mareko>
I guess nvc0 removal is also on the table
<airlied>
I think it will live forever pre-kepler
<airlied>
maybe I'll feel like doing a crocus on it someday :-P
<mareko>
I should run viewperf on zink some day, it might be interesting
<mareko>
and same for aco
glennk has quit [Ping timeout: 480 seconds]
enick_864 is now known as DrNick
neniagh_ has joined #dri-devel
neniagh has quit [Ping timeout: 480 seconds]
bbaa has joined #dri-devel
bbaa has quit []
Company has quit [Quit: Leaving]
konstantin has joined #dri-devel
bmodem has joined #dri-devel
alatiera has quit [Quit: Connection closed for inactivity]
konstantin_ has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
Haaninjo has quit []
rgallaispou has quit [Read error: Connection reset by peer]
<gfxstrand>
Yeah, beating nvc0 is not a high bar....
<gfxstrand>
TBH, that's the only reason why Zink is a viable plan for nouveau
<gfxstrand>
If we had a competent GL driver, we probably wouldn't be nearly as quick to talk about tossing it.
<gfxstrand>
But nvc0 is NOT a competent GL driver by any means.
<gfxstrand>
And, yeah, AGX constraints are very different from NVK constraints.
<gfxstrand>
AGX is "We have nothing and we want GNOME running ASAP" while NVK was "We have a shitty GL driver that runs your desktop fine but people want to be able to play games."
<gfxstrand>
With the second, "Vulkan + DXVK or bust!" is a reasonable take. With the former, it's way less clear that that's a competent plan.
<gfxstrand>
IDK that REing GL is any easier than Vulkan.
<gfxstrand>
But getting GNOME to run on native gallium is a hell of a lot easier than GNOME on Zink on Vulkan.
i-garrison has quit [Remote host closed the connection]
<mripard>
melissawen: my personal metric is whether or not it actually fixes something, or if it's theoretical
<mripard>
so if it's tied to a bug or breakage, it goes to -fixes
<mripard>
if it's just something that was noticed but doesn't really affect anyone, -next
<melissawen>
mripard, got it. Thanks for explaining. I checked who is using this function and indeed I need an ack from msm people too.
<melissawen>
it seems they put conditionals to zero values that prevent the bug in their side
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
ascent12_ has quit []
ascent12 has joined #dri-devel
pcercuei has joined #dri-devel
<tnt>
In vulkan compute shader, is several thread of a local group writing to the same shared variable a defined behavior ? I have a shared bool initialized to false and then threads can set it to true but seems if several do it, it ends up none of the write succeed and it keeps being evaluated to false.
<dj-death>
tnt: likely undefined
<dj-death>
tnt: use atomics if you write to the same location using multiple threads
kts has joined #dri-devel
<tnt>
dj-death: thanks, I'll look into that. (the bool is a termination condition so the shader is while (!g_done) { ... do something that might set g_done ... }. )
<sima>
mripard, so one think I realized while doing my fri workout is that drm_atomic_commit could have a risk for a commit_commit function name
<sima>
but the few I checked look all good, like drm_atomic_check|commit|nonblocking_commit
<sima>
but if we have a really awkward one then maybe atomic_update and more renaming could be the winner instead
AnuthaDev has joined #dri-devel
<mripard>
jani: thanks for the follow-up patch
<mripard>
sima: I think it'll work out with commit, and yeah, worst case scenario we can catch it during review
<pq>
hwentlan__, I finally took the time to go through your colorop series. Please, take everything I said as observations and suggestions, and nothing more.
iive has joined #dri-devel
aravind has joined #dri-devel
macslayer has joined #dri-devel
dviola has joined #dri-devel
maxzor has joined #dri-devel
maxzor has quit [Remote host closed the connection]
<jani>
mripard: np, I hope it fixes the CI issues we're having
jewins has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
JohnnyonFlame has joined #dri-devel
naahmed has joined #dri-devel
Company has joined #dri-devel
naahmed has left #dri-devel [#dri-devel]
naseer has joined #dri-devel
Haaninjo has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
Guest9652 has quit [Read error: Connection reset by peer]
DodoGTA has joined #dri-devel
camus has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
mripard has quit [Remote host closed the connection]
donaldrobson has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
Duke`` has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
tzimmermann has quit [Quit: Leaving]
naseer has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
jfalempe has quit [Quit: Leaving]
glennk has quit [Ping timeout: 480 seconds]
ickle has quit [Ping timeout: 480 seconds]
donaldrobson has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
i509vcb has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
alyssa has quit [Quit: alyssa]
naseer has joined #dri-devel
sigmaris_ has quit []
Anorelsan has joined #dri-devel
sigmaris has joined #dri-devel
hansg has quit [Quit: Leaving]
AnuthaDev has quit []
Mangix has quit [Remote host closed the connection]
Mangix has joined #dri-devel
Anorelsan has quit [Quit: Leaving]
gwaldron has joined #dri-devel
digetx has quit [Ping timeout: 480 seconds]
rz_ has quit [Remote host closed the connection]
rz has joined #dri-devel
merineitsi has joined #dri-devel
gouchi has quit [Quit: Quitte]
merineitsi has quit [Quit: Leaving]
glennk has joined #dri-devel
digetx has joined #dri-devel
bbrezillon has quit [Ping timeout: 480 seconds]
bbrezillon has joined #dri-devel
fab has quit [Quit: fab]
benjaminl has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
benjaminl has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
bbrezillon has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
rgallaispou has left #dri-devel [#dri-devel]
Duke`` has quit [Ping timeout: 480 seconds]
bbrezillon has joined #dri-devel
mvlad has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
crabbedhaloablut has quit []
glennk has joined #dri-devel
glennk has quit [Read error: Connection reset by peer]
glennk has joined #dri-devel
sima is now known as Guest9682
sima has joined #dri-devel
<mareko>
daniels: FYI, kernel 6.5 (or 6.4?) has a new mitigation for an AMD CPU security vulnerability in Zen 1-4 (Speculative Return Stack Overflow), which can double the time for piglit to finish in CI
<mareko>
we haven't seen any notable difference in GLCTS and dEQP run times except dEQP-EGL, which can take 10x longer to finish
<mareko>
booting with spec_rstack_overflow=off disables the mitigation
<daniels>
mareko: thankyou! that’s really helpful
<daniels>
DavidHeidelberg: ^
<mareko>
dEQP-EGL = 10x longer, piglit = 2x longer, others = not much difference