sukuna has quit [Remote host closed the connection]
moxie has joined #dri-devel
caitcatdev has joined #dri-devel
sukuna1 has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
The_Company has quit []
vedranm has quit [Quit: leaving]
vedranm has joined #dri-devel
fab has joined #dri-devel
fab is now known as Guest59
jsa1 has joined #dri-devel
Duke`` has joined #dri-devel
tzimmermann has joined #dri-devel
gnuiyl has joined #dri-devel
cascardo_ has joined #dri-devel
cascardo has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
Guest59 has quit []
tobiasjakobi has quit []
dolphin has joined #dri-devel
kts has joined #dri-devel
kts has quit [Quit: Leaving]
karenw has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit []
aradhya7 has quit [Quit: Connection closed for inactivity]
fab has joined #dri-devel
fab is now known as Guest63
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
parthi has joined #dri-devel
frieder has joined #dri-devel
parthiban has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
androidui has quit [Read error: Connection reset by peer]
apinheiro has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
glennk has joined #dri-devel
mripard has joined #dri-devel
frankbinns has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
<MrCooper>
Lynne: rgb24 isn't trivial to handle in HW, that's why non-ancient HW tends not to support it; I'd assume at least the 32 bpc variant to be supported though
Haaninjo has joined #dri-devel
<Lynne>
fair enough
parthi has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
lynxeye has joined #dri-devel
dt9_ is now known as dt9
Dalphon_ has left #dri-devel [#dri-devel]
unalmasIRC has joined #dri-devel
bmodem has joined #dri-devel
vliaskov has joined #dri-devel
sima has joined #dri-devel
frieder has joined #dri-devel
kts has joined #dri-devel
heat has joined #dri-devel
jkrzyszt has joined #dri-devel
rasterman has joined #dri-devel
kts has quit [Quit: Leaving]
jkrzyszt_ has joined #dri-devel
blaztinn_ has joined #dri-devel
blaztinn has quit [Read error: Connection reset by peer]
jkrzyszt has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
parthiban has joined #dri-devel
LeviYun has joined #dri-devel
yshui has joined #dri-devel
yshui_ has quit [Ping timeout: 480 seconds]
diego has joined #dri-devel
<luc>
ctx->syncobj?
<luc>
Hi! I'm trying to understand how syncobjs work. Does anyone know why creating a pipe_fence_handle (like panfrost_fence_create) requires 1) ExportSyncFile ctx->syncobj 2) Create a new syncobj 3) ImportSyncFile the exported syncobj into the new one again, rather than directly assign ctx->syncobj to newly-allocated pipe_fence_handle *f->syncobj? Is that because it requires the kernel to replace the fence which adheres to original
yshui_ has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
yshui_ has quit [Ping timeout: 480 seconds]
<MrCooper>
luc: FWIW, drm_syncobjs and sync_files are completely different beasts, so " 3) ImportSyncFile the exported syncobj into the new one again" doesn't make sense
yshui has joined #dri-devel
<MrCooper>
in some cases, one has to transfer the sync_file from a non-0 syncobj timeline point to timeline point 0 of a separate syncobj, because some syncobj ioctls operate only on timeline point 0
<luc>
what I don't understand is why not assign the original ctx->syncobj to f->syncobj directly there
yoz_ has quit []
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
<MrCooper>
luc: a syncobj is a container which can have multiple timeline points, each of which can hold a fence (which is what a sync_file represents)
<MrCooper>
the sequence you described sounds like creating a new syncobj which holds the same fence as the original one, maybe the original one can't be used directly for some reason
<luc>
MrCooper: thanks very much!
apinheiro has quit [Quit: Leaving]
warpme has quit []
himalg has joined #dri-devel
himal has quit [Ping timeout: 480 seconds]
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
Kayden has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
hansg has joined #dri-devel
warpme has joined #dri-devel
diego has left #dri-devel [#dri-devel]
dviola has joined #dri-devel
jfalempe has joined #dri-devel
rgallaispou has joined #dri-devel
apinheiro has joined #dri-devel
davispuh has joined #dri-devel
tango_ has quit [Ping timeout: 480 seconds]
warpme has quit []
heat has quit [Read error: Connection reset by peer]
pepp has joined #dri-devel
heat has joined #dri-devel
tango_ has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
Dr_Who has joined #dri-devel
HerrSpliet has joined #dri-devel
RSpliet has quit [Read error: No route to host]
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
heat is now known as Guest84
Guest84 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
warpme has joined #dri-devel
nerdopolis has joined #dri-devel
himalg has quit [Remote host closed the connection]
Haaninjo has quit [Read error: Connection reset by peer]
Haaninjo has joined #dri-devel
Company has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
bolson has joined #dri-devel
dsimic is now known as Guest90
dsimic has joined #dri-devel
Guest90 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
dolphin has quit [Quit: Leaving]
Guest63 has quit [Ping timeout: 480 seconds]
ity has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
<MrCooper>
hmm, is there really no EGL way to determine if a GPU is integrated or discrete?
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
ptrc has quit [Remote host closed the connection]
ptrc has joined #dri-devel
<MrCooper>
thanks
fab has joined #dri-devel
fab is now known as Guest93
bolson_ has joined #dri-devel
Guest93 has quit []
bolson has quit [Ping timeout: 480 seconds]
amarsh04 has quit []
<tomba>
I have the bootloader setting up an area of memory for a splash screen, which is then on the screen when Linux boots up. I was thinking that it would be nice if the Linux DRM driver could create the fbdev and tell it to use that piece of memory as the buffer. Is this something that can be achieved without implementing it all in the driver?
<mripard>
tomba: so there's two "features" in your question. The first one is exposing a bootloader splash screen to Linux, and x86 has something kind of like that through ACPI, which is supported by plymouth and all through a sysfs file iirc. Adding a similar DT mechanism would be pretty easy.
<mripard>
then, you also want to have a seamless transition between both, and that will require both driver and framework changes as of todya
amarsh04 has joined #dri-devel
<javierm>
mripard: /sys/firmware/acpi/tables/BGRT is the sysfs entry you meant
<mripard>
javierm: thanks
<javierm>
tomba: and yeah, having a flicker-free boot on ARM with DT like we can have with ACPI using BGRT would be pretty cool
<mripard>
javierm: like I said, flicker free boot isn't just about getting the splash screen
<mripard>
that's the easy part actually :)
<tomba>
mripard: what does the ACPI stuff do there? in my WIP branch, I just mark the memory as reserved in the DT. as a hack, I then modified tidss driver to create the DRM fbdev, and copy the memory from the bootloader's fb to the newly allocated DRM fb. this was ugly, but it "worked".
<tomba>
although I guess this is all somewhat platform specific. in the tidss case we have lots of trouble related to the powerdomains in this scenario, where we want to keep the display HW enabled even if we don't have a driver yet in control.
<tomba>
as for the second part, I think it should be fine if the first modeset we get is for the fbdev (preferably with bootloader's fb). but again, platform specific, in tidss case we need to be careful with what we do in probe to not mess things up.
<tomba>
but as I don't have things properly working, I'm sure I might be missing some details =)
kts has joined #dri-devel
frieder has quit [Remote host closed the connection]
<tomba>
one problem I also faced was that if the main driver (tidss) is a module, but we want to use simpledrm as an early driver to allow boot time apps to show something, then there can problem at the time the simpledrm is removed (drm_aperture_remove_framebuffers or such), which, I think, should preferably be done before adding the new DRM fbdev.
<mripard>
tomba: basically, for it to work properly, to need to create a mode test that matches what your hardware is currently running when you probe
damo22 has joined #dri-devel
<tomba>
mripard: yes, I can just check the display subsystem registers to find out what the bootloader has set up
<mripard>
s/mode test/state/ sorry
<dcbaker>
alyssa: I would continue to do so just to be in the habit, since hopefully we'll reach a day that you can just say "use the official releases, uAPI is stable"
<alyssa>
dcbaker: yeah... I mean the flip side is that I really appreciate being able to do my own releases
<alyssa>
but obviously eventually debian stable or whatever should be able to run with the upstream releases
<alyssa>
..slowly
jkrzyszt_ has quit [Ping timeout: 480 seconds]
<dcbaker>
Its always a tradeoff between what's easiest for upstream and what's easiest for downstream isn't it?
<dcbaker>
So, speaking of releases. We have one open blocker, which is extra symbols exposed on MacOS from osmesa. That was caused by @zmike, who is on vacation the rest of the year. Does anyone care enough to fix it or to keep it as a blocker, or can I remove it and make 24.3.0 this week? https://gitlab.freedesktop.org/mesa/mesa/-/issues/11659
<alyssa>
given the state of mesa on macOS, I don't see why that should block release imho
<daniels>
I think it's reasonable to ask the people who use + develop + care about Mesa on macOS to fix that one, rather than hoping someone can figure it out by manpages, googling, and throwing patches out for someone to test
Dr_Who has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
<alyssa>
cmarcelo: ^ real OpenCL code from my branch
<jenatali>
alyssa: That sounds like it should be paired with a "they've played us for absolute fools" meme
Calandracas_ has joined #dri-devel
<cmarcelo>
alyssa: oh, another way to frame is you adding new "intrinsics" to OpenCL...?
<alyssa>
jenatali: stop doing nir_builder
<alyssa>
cmarcelo: sure
kaiwenjon has quit [Quit: WeeChat 3.8]
Calandracas has quit [Ping timeout: 480 seconds]
<Kayden>
dcbaker: agree with the others, I don't think macos symbols should be a release blocker esp. given we don't have really anybody developing that these days
<glehmann>
alyssa: so when are you going to write a nir C frontend to remove the llvm dependency
Ermine has quit [Ping timeout: 480 seconds]
lina has quit [Quit: Ping timeout (120 seconds)]
lina has joined #dri-devel
Ermine has joined #dri-devel
coldfeet has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
kaiwenjon has joined #dri-devel
apinheiro has quit [Quit: Leaving]
<alyssa>
glehmann: you know, I've thought about it.
tlwoerner_ has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
<karolherbst>
ah yeah, the magical C nir frontend we talk about every 6 months
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: though the issue is simply that you need custom functions which translate to custom intrinsics, no? We can already do that
<karolherbst>
or well.. it would be trivial to add
epoch101 has joined #dri-devel
<jenatali>
Seems like the point is to remove manual steps and just write nir intrinsics directly?
<karolherbst>
sure, but you can do that already
<karolherbst>
like you could add internal functions and resolve them at link time, then you just need a lib to link against. I think you can even add more builtins at the clang API level to make that a bit nicer
<jenatali>
Sure, it's just promoting all (or more realistically some) nir functions to do that automatically I presume
<karolherbst>
yeah
rgallaispou has quit [Remote host closed the connection]
<karolherbst>
functions starting with __ are considered internal stuff, so we could use them to do whatever we want
<alyssa>
karolherbst: it's just a nir pass that runs at link time to resolve nir_* functions to opcodes&intrinsics
<karolherbst>
yeah
<karolherbst>
it shouldn't be too hard to do
<alyssa>
I already did it lol
<karolherbst>
ahh
<karolherbst>
lol
<alyssa>
i should start posting MRs
<alyssa>
you down for reviewing an absurd # of cross-tree patches? :P
<karolherbst>
sadly we can't tell the translator to emit a custom extinst set
<karolherbst>
that would allow for more funky/cleaner things
<karolherbst>
alyssa: uhhh... sure
<alyssa>
:>
<karolherbst>
though I'd like to have a more streamlined way of adding builtin functions. The pain point obviously is to deal with compile time constants, but I think we might even be able to create something nice with most of it just being generated code
<alyssa>
Is this non-harmful on amd / hw with native int64?
<alyssa>
I assume so but want to check if I should be predicating on lower_int64
<karolherbst>
ohh right, one of your patches broke llvmpipe 🙃
<alyssa>
um
<karolherbst>
but like...
<karolherbst>
in a "llvmpipe was already broken" way
<karolherbst>
something with corotines and functions and being in a weird state
<Company>
once you fix llvmpipe, you can also fix it on Windows
<glehmann>
alyssa: ugh, it's better for amd hw (or at least not worse for the SALU). But the question is if aco's RA gets in the way (but even if it does, I think the patch is okay as is)
<alyssa>
good enough for me :P
<alyssa>
thx
<glehmann>
might make sense to also add a <= UINT32_MAX, a < (UINT32_MAX + 1) and (UINT32_MAX + 1) >= a?
<Company>
alyssa: btw, I noticed hk is missing from features.txt - is that an oversight or on purpose?
<alyssa>
glehmann: maybe? Idk if any apps will hit these patterns, it's just something that NIR generates internally when lowering opencl
<glehmann>
fair
<glehmann>
also TIL nir_intrinsic_convert_alu_types exists
<alyssa>
Company: on purpose, features.txt is silly
<glehmann>
why is it not alu though
<alyssa>
because then someone would need to write constant folding..
Guest117 has quit [Read error: Connection reset by peer]
<Company>
that reminds me I wanted to check what goes on with vkPresent() blocking on Windows
<alyssa>
glehmann: ok not yet but probably in 2025
<alyssa>
apparently i'm supposed to do my day job or something sometimes though
coldfeet has quit [Remote host closed the connection]
* alyssa
has to run but will continue opening MRs tomorrow (:
u-amarsh04 has joined #dri-devel
iive has joined #dri-devel
danylo is now known as Guest119
danylo has joined #dri-devel
Guest119 has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit []
amarsh04 has joined #dri-devel
<karolherbst>
airlied: mind figuring out why 2a3f133fd0538cc3a8cde314b8cf5b23bff7f12a broke "non_uniform_work_group/test_non_uniform_work_group non_uniform_1d_atomics" with llvmpipe?
<karolherbst>
I _think_ it's just bad luck with how functions are implemented and the compiler hitting a barrier while the coro stuff isn't set up yet