ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
iive has quit [Quit: They came for me...]
<DavidHeidelberg> mareko: figured out. s390x and ppc64el finished builds one minute later... and since when you crosscompile somehow you need to have synced native and cross packages (at least for stuff like libdrm)....
<DavidHeidelberg> so amd64 was tagged with version one minute younger and that created the conflict
pcercuei has quit [Quit: dodo]
<mareko> alyssa: I don't think transform feedback should be followed by glMemoryBarrier, that should be done automatically in drivers that need it
Haaninjo has quit [Quit: Ex-Chat]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
<alyssa> mareko: Hmm, okay. TBH I find the glMemoryBarrier() spec pretty unclear
<alyssa> I guess the relevant text is "stores performed by shaders", which includes SSBOs but not XFB.
<alyssa> OK, that's annoying but I can figure something out
<DavidHeidelberg> mareko: for the libdrm, believe me it was so much pain from CI maintainer perspective. it was just no-one needed libdrm upgrade for too long, so I worked on different stuff meanwhile as the Debian 12 version was just fine, btw. my MR is fixed, seems that everything working
gabertron_ has joined #dri-devel
gabertron is now known as Guest13126
gabertron_ is now known as gabertron
Guest13126 has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Ping timeout: 480 seconds]
Stary has quit [Quit: ZNC - http://znc.in]
Stary has joined #dri-devel
<jenatali> alyssa: right, ssbos and storage images. Nothing that's "fixed function" which happens after a shader stage
<DavidHeidelberg> Reviews are welcome, it's first package, but lot of others "coming soon ™)
<DavidHeidelberg> mareko: builds working, libdrm is everywhere same, life should be nice, feel free to merge before applying your change :)
<DavidHeidelberg> (I tested with your commit increasing the requirement, so it should be fine)
<mareko> thanks, I added my Rb
<mareko> alyssa: radeonsi adds the barrier when it unbinds streamout buffers
maxzor_ has quit [Ping timeout: 480 seconds]
krushia has quit [Quit: Konversation terminated!]
bbrezillon has quit [Read error: Connection reset by peer]
bbrezillon has joined #dri-devel
Company has joined #dri-devel
camus has quit []
camus has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
a-865 has quit [Quit: ChatZilla 0.18 [SeaMonkey 2.53.18/20231128201643]]
a-865 has joined #dri-devel
yyds_ has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Duke`` has joined #dri-devel
crabbedhaloablut has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #dri-devel
loki_val has joined #dri-devel
fab has joined #dri-devel
glennk has joined #dri-devel
crabbedhaloablut has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.1.2]
lemonzest has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
sima has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
fab_ has joined #dri-devel
Leopold_ has joined #dri-devel
xq has joined #dri-devel
fab_ is now known as Guest13151
fab has quit [Ping timeout: 480 seconds]
AnuthaDev has joined #dri-devel
pcercuei has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
kts has joined #dri-devel
Haaninjo has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
ungeskriptet is now known as Guest13162
ungeskriptet has joined #dri-devel
Guest13162 has quit [Ping timeout: 480 seconds]
<gio> I guess there is no FOSS Vulkan driver for the Adreno 540, is that right?
kts has quit [Ping timeout: 480 seconds]
<DavidHeidelberg> gio: Nope, only GL
kts has joined #dri-devel
heat has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
tristianc6704 has quit []
tristianc6704 has joined #dri-devel
<alyssa> jenatali: :+1:
<alyssa> mareko: Hmm, interesting, ok.
kts has quit [Quit: Leaving]
<alyssa> My problem is that I do draw call reordering shenanigans so it'd need to be a full flush (big hammer), though maybe I should just.. stop doing that for XFB lol
<jenatali> Yep
<jenatali> Transform feedback needs to be ordered, doesn't it?
<alyssa> jenatali: Hmm?
tristianc6704 has quit []
glennk has quit [Ping timeout: 480 seconds]
tristianc6704 has joined #dri-devel
<jenatali> Like fragment shader writes, I thought XFB writes need to respect the original draw order
<alyssa> Ah. Yeah
<alyssa> Probably
<alyssa> The problem is that for dubious reasons, right now I execute all the XFB for the render pass before executing any FS, for example
<alyssa> Although to some extent that's kinda inevitable for tilers..
qyliss has quit [Quit: bye]
qyliss has joined #dri-devel
<jenatali> Yeah that seems fine
tlwoerner_ has joined #dri-devel
zxfhh[m] has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
Leopold_ has quit []
yyds_ has quit [Remote host closed the connection]
JohnnyonFlame has quit [Read error: Connection reset by peer]
<alyssa> pac85: So, nir_passthrough_gs with out prim != in prim is broken with transform feedback
<alyssa> E.g. TRIANGLES input, polygon mode set to LINES, transform feedback enabled, edge flags enabled
<alyssa> nir will output LINE_STRIPS from the passthrough GS, which makes edge flags work, but breaks XFB since XFB needs to be triangles
<alyssa> I suspect Zink is affected at least in theory
<alyssa> "edge flags can't be used in the same draw as XFB" would solve this, I just don't know if it's true
<pac85> alyssa: yep, I think we talked about it right? In zink I force the passtrhough gs to tesselate (so triangle out) geometry so that transform feedback behaves (hopefully) to spec, but that means breaking rendering on some cases
<alyssa> ah..
<pac85> alyssa: we also need to handle quads in line mode in zink
<alyssa> :clown:
<alyssa> faith was right I should've gone vulkan
maxzor has joined #dri-devel
<Wallbraker> *sad trombone*
Leopold_ has joined #dri-devel
glennk has joined #dri-devel
<alyssa> *tiniest violin*
<ccr> *Benny Hill Yakety Sax -theme*
<Company> the good thing about Vulkan is that all the other drivers aren't debugged as well either, so you're not the only one looking bad
<Company> the bad thing about Vulkan is that all the apps are coded against those drivers and not against the spec
<alyssa> Company: so like gl
<Company> yeah, but gl has had 20 years to get apps and drivers to agree on most stuff
<Company> and even write it down sometimes
<Company> I merged the new GTK renderer today, which can do Vulkan and GL - and now I'm wondering how to select which one to use
<jenatali> alyssa: Our driver has a post-process pass on the XFB buffer to produce a correct output
<Company> because GL is gonna be safer and Vulkan is gonna find all the bugs
<alyssa> jenatali: Oof.
<jenatali> We also do some shenanigans with queries to return correct primitive counts IIRC
<alyssa> jenatali: Oof.
<jenatali> Yeah
<jenatali> I still doubt it's all right, but we try at least
<Company> Is that stuff even used a lot?
<Company> or is this more a case of "make it work well enough so it passes the tests"?
kts has joined #dri-devel
<alyssa> #2
<jenatali> Agreed
<jenatali> The pieces might individually be useful but the combinations absolutely aren't
<Company> so it's a case of doing it wrong when thinking about how it's broken
kzd has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
<soreau> Company: if GL is safer, make it the default and an env var to pick vulkan?
<soreau> Then later, you can switch on Vulkan by default and make phoronix again
<Company> that's how it works already
<Company> but the question is how to determine if that magical "later" has arrived
<soreau> testing, CI, etc..
paulk-bis has joined #dri-devel
paulk has quit [Read error: Connection reset by peer]
<soreau> maybe if GL setup fails, try Vulkan before falling back or whatever
<Company> that's also already how it works
kzd has joined #dri-devel
<soreau> sounds like you have most loose ends tied up, I assume you aren't going to try zink internally or anything
kts has quit [Quit: Leaving]
<soreau> but somehow I doubt folks will complain that it's GL and not Vulkan unless stuff just isn't working
<Company> yeah, but I'd expect "stuff just isn't working" to be more common on Vulkan
<Company> and people aren't complaining either way I don't think
<Company> it's not like anyone but me does performance measurements of GTK
<JoshuaAshton> I would have thought Vulkan would have been pretty robust given the insane shit the majority of games do
<Company> depends - because desktop apps often do the things that games don't do
<JoshuaAshton> Curious as to what you have in mind
<JoshuaAshton> From my perspective desktop apps draw textured quads and not much else :frog:
<Company> yeah
<Company> in that sense that's pretty easy
<Company> the problem is that desktop apps (or rather: toolkits) don't know what they are going to draw
<Company> like, there might be an image viewer deciding to load 5000 images
<Company> and then your vram is full
<Company> or a text editor goes and zooms out and suddenly your command buffers get insanely big
<pac85> That's a problem regardless of vk or gl through isn't it?
<JoshuaAshton> Depends whether you defer resource uploading until first use or not
<Company> GL does better memory management than Vulkan
<JoshuaAshton> Well, VK does no memory management by design
<JoshuaAshton> that is on you now
<Company> yeah, and GL knows what it's doing and I don't
<JoshuaAshton> It is still probably safe-ish though as long as you aren't using bindless
<JoshuaAshton> TTM will page in/out the BOs related to the images you use in your descriptor sets per-submission
<Company> yeah, but you only figure out you messed up when it's too late
<Company> because it's often not me but the app developer or their users who experience it
<Company> and if GTK screws up its GPU stuff, people blame GTK, not the app
<Company> because the other toolkits don't have that problem
<JoshuaAshton> Shout out to all the "gamescope crashes" that are actually just device loss from a game
<Company> whereas if a game screws up its gpu stuff, people blame the game, not the engine
<Company> which is as it should be - but it means I need to judge things differently than games
<JoshuaAshton> At least on AMD discrete you don't have that to worry about, if either side fucks up then absolutely everything goes down ;D
<Company> that's why I'm developing on AMD discrete!
<Company> and in F39 I'm only thrown back into gdm and don't have to reboot, so progress
<JoshuaAshton> Yeah
<Company> that's another thing I haven't thought about much - how to deal with the fact that the GPU is shared
<JoshuaAshton> On Steam Deck at least only the game should die... but some recent gamescope crashes seem to indicate there might have been some regression there in 3.5 that we need to prod at
<Company> people tend to open 20 apps and then launch their game
<JoshuaAshton> There is not much that you can do aside from: don't render when you don't need to, and maybe give yourself a low queue priority.
<Company> I was mostly thinking about freeing the memory
<JoshuaAshton> Eh that's not your job
<JoshuaAshton> TTM can deal with that
<JoshuaAshton> If we had explicit residency, you could manually page things out
<Company> but the usual GTK app needs a few 100k of vram, so meh
<Company> but the fun stuff are always the exceptions
<Company> and yeah, me not having a clue about memory management is one of the examples why Vulkan might be worse than GL
<JoshuaAshton> AIUI, the GL driver isn't automatically freeing memory and reuploading behind the scenes when idle and is simply relying on TTM manage residency, so you also shouldn't need to do anything
<Company> good to know
<Company> on my rpi only the Vulkan driver OOMs for me though
<Company> but that might be the driver, I didn't investigate that far yet
JohnnyonFlame has joined #dri-devel
camus has quit []
AnuthaDev has quit []
<JoshuaAshton> One thing GTK will probably need to do is it's own suballocation
<JoshuaAshton> That might be what you are seeing there
<Company> I do that already
<Company> a pretty dumb version, but good enough so far
<Company> things get really slow if nautilus puts every thumbnail into its own VkDeviceMemory
<soreau> Company: does anything vulkan oom, or only your gtk test?
<Company> drivers don't like that
<soreau> like vkcube works or anything?
<Company> soreau: if my test goes oom, the gpu resets and all apps using the gpu go down
<Company> because AMD discrete
<soreau> Company: right but I was asking if other vulkan apps work on rpi
<Company> oh, rpi
<Company> I didn't test that yet
<Company> anyway, if anyone has a good heuristic to select Vulkan vs GL, tell me
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
<Company> good news: vkcube also crashes
glennk has quit [Ping timeout: 480 seconds]
vliaskov_ has joined #dri-devel
<soreau> Company: Does vulkaninfo work?
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
vliaskov has joined #dri-devel
vliaskov_ has quit [Read error: Connection reset by peer]
maxzor has quit [Ping timeout: 480 seconds]
paulk-bis has quit []
paulk has joined #dri-devel
glennk has joined #dri-devel
staffanu has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
Guest13151 has quit []
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
loki_val has quit []
crabbedhaloablut has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
staffanu has quit []
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
RSpliet has quit [Read error: Connection reset by peer]
RSpliet has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
AnuthaDev has joined #dri-devel
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
flom84 has joined #dri-devel
AnuthaDev has quit [Quit: AnuthaDev]
vliaskov has joined #dri-devel
flom84 has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
yrlf has quit [Quit: The Lounge - https://thelounge.chat]
yrlf has joined #dri-devel
pcercuei has quit [Quit: dodo]
glennk has quit [Ping timeout: 480 seconds]
jeeeun841351908 has quit [Remote host closed the connection]
jeeeun841351908 has joined #dri-devel