ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
simondnnsn has joined #dri-devel
yann-kaelig has joined #dri-devel
flynnjiang has joined #dri-devel
camus has joined #dri-devel
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
luben has joined #dri-devel
yyds has joined #dri-devel
luben has quit [Remote host closed the connection]
luben has joined #dri-devel
yuq825 has joined #dri-devel
luc has quit [Quit: Page closed]
yann-kaelig has quit []
Aura has quit [Ping timeout: 480 seconds]
yyds_ has joined #dri-devel
yyds has quit [Read error: Connection reset by peer]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
yyds_ has quit []
yyds has joined #dri-devel
flynnjiang1 has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
simondnnsn has quit [Remote host closed the connection]
glennk has joined #dri-devel
luben has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
Company has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
fab has joined #dri-devel
itoral_ has joined #dri-devel
Leopold__ has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
OftenTimeConsuming is now known as Guest13289
OftenTimeConsuming has joined #dri-devel
Guest13289 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
glennk has quit [Ping timeout: 480 seconds]
<mareko>
the limitation of vulkan is that DMABUF requires modifiers
<mareko>
X.Org won't give you modifiers with the DDX that supports FreeSync and TearFree
<Company>
isn't that a limitation of X.Org more than Vulkan?
vliaskov_ has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
simondnnsn has joined #dri-devel
pjakobsson has joined #dri-devel
frieder has joined #dri-devel
sima has joined #dri-devel
<mareko>
it's only a limitation of the DDX
<mareko>
some other DDXs support modifiers
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
aknautiy has joined #dri-devel
frieder has quit []
frieder has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
fab has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
infinitesimalCheese has joined #dri-devel
infinitesimalCheese has quit []
simondnnsn has joined #dri-devel
jfalempe has joined #dri-devel
mvlad has joined #dri-devel
frankbinns has joined #dri-devel
frankbinns1 has joined #dri-devel
lynxeye has joined #dri-devel
apinheiro has joined #dri-devel
<MrCooper>
Company: "a few 100k of vram" with at least 2 surface buffers, that's a small window :)
<Company>
well, that's managed by libvulkan - I was only thinking about VkDeviceMemory I handle myself
glennk has joined #dri-devel
<Company>
I also have no idea how much memory the driver allocates for the command buffers
frankbinns has quit [Ping timeout: 480 seconds]
<Company>
I only know how many images I allocate for icons, the vertex buffer and things like that
pcercuei has joined #dri-devel
<Company>
but in general I want to be able to delete everything on the GPU and recreate it from scratch
<Company>
because then I can deal with GPU resets
tursulin has joined #dri-devel
<Company>
but then I can also delete everything if the app has been unused in the background for long enough
rasterman has joined #dri-devel
<MrCooper>
makes sense, there's now a suspended state Wayland protocol for the latter
frankbinns1 is now known as frankbinns
<Company>
right, it might make sense to listen to that, too
<sima>
airlied, imre drm-tip is fixed
vliaskov_ has joined #dri-devel
hansg has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
orowith2os[m] has joined #dri-devel
vliaskov__ has joined #dri-devel
xroumegue has joined #dri-devel
rgallaispou has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
<MrCooper>
agd5f: not sure it's really a good idea to ask Markus Elfring to re-send a patch series from 2016 :/
jeeeun841351908 has quit [Read error: Connection reset by peer]
jeeeun841351908 has joined #dri-devel
<ccr>
:D
flynnjiang1 has quit []
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
glennk has joined #dri-devel
<CounterPillow>
rofl
<CounterPillow>
Too bad you can only ban him from the mailing list and not from individual developers' inboxes
<Company>
amdgpu: The CS has been rejected (-22).
<Company>
okay, now I broke it
<karolherbst>
jenatali, airlied: I'm looking into the llvm spirv backend now, because llvm-17 forcing opaque pointers breaks most of the compiler tests as function forward declarations with the translator are just broken :(
<karolherbst>
and I want to know if it's better with that anyway
kts has joined #dri-devel
rsalvaterra has quit []
kts has quit []
rsalvaterra has joined #dri-devel
shashanks has joined #dri-devel
kts has joined #dri-devel
kts has quit [Quit: Leaving]
padovan has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.1.2]
lemonzest has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
mwk_ has quit [Remote host closed the connection]
mwk has joined #dri-devel
yyds has quit [Remote host closed the connection]
fab has quit [Ping timeout: 480 seconds]
vliaskov__ has quit [Read error: No route to host]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
camus has quit []
Tenzap has joined #dri-devel
camus has joined #dri-devel
fab_ has joined #dri-devel
fab_ is now known as Guest13331
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
<alyssa>
good luck ^^
Tenzap has quit [Remote host closed the connection]
<jenatali>
karolherbst: cool, let me know how it goes
<karolherbst>
I tried to figure out why my translator didn't compile for an hour just to notice that my ~/local prefix had stale files in it :')
kts has joined #dri-devel
Arsen has quit [Quit: Quit.]
<karolherbst>
forgot to build the spirv target :')
<jenatali>
Sounds like me in December, realizing that I've been installing libclc to the wrong drive for literal years which was causing some math failures
<karolherbst>
... pain
<jenatali>
But only in my local dev builds at least
Arsen has joined #dri-devel
<karolherbst>
now I have to figure out how to get the spirv...
<alyssa>
oof
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<karolherbst>
I should check what llvmpipe is doing, not what radeonsi is doing :D
kts has quit [Ping timeout: 480 seconds]
itoral_ has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit []
yyds has joined #dri-devel
kts has joined #dri-devel
kts has quit []
Guest13331 has quit []
jfalempe has quit [Remote host closed the connection]
<karolherbst>
that's when forward declaring functions ...
<karolherbst>
so it's not fixing the issue I hoped it would fix :D
<jenatali>
Oof
<karolherbst>
well.. it's llvm-17
<karolherbst>
I shall try llvm-18, llvm-main and then complain to them they should fix it and see them falling into eternal dispair as opaque pointers makes it a pain to support
<karolherbst>
yo....
<karolherbst>
it's broken
<karolherbst>
Source and destination types of SpvOpStore do not match: uint8_t (%8) vs. uint64_t (%9)
<karolherbst>
just trying to run math_brute_force
<karolherbst>
the translator is already a nightmare in terms of producing valid spir-v
<karolherbst>
it seems that llvm target is worse
<karolherbst>
pain... fedora LLVM doens't build the spirv backend :')
<alyssa>
D:
<karolherbst>
let's see if patching the spec file is trivial here :D
<jenatali>
Guess I'm just going to be stuck on LLVM 16 or older forever. The beauty of statically linking is I get to pick my version and don't have to care about what else is on the system
<karolherbst>
:D
<karolherbst>
well.. requiring the SPIRV target is easy to do and it seems like you have to do 0 changes to the packaging
kzd has joined #dri-devel
<mupuf>
MrCooper: hmm, that's indeed a good point!
<karolherbst>
distributions will hate me when I say: <llvm-17 :D
frieder has quit [Remote host closed the connection]
fab has joined #dri-devel
<alyssa>
is that an option
<karolherbst>
jenatali: somebody on the spirv-llvm-translator bug tracker suggested that we should just convert the spirvs to llvm and link on the llvm level
<karolherbst>
seriously... writing an OpenCL C to SPIR-V compiler becomes a better idea every llvm release
<jenatali>
Ugh. I guess we could do SPIR linking instead of SPIR-V linking but oof that sounds like a terrible idea for app-provided SPIR-V
<karolherbst>
well
<karolherbst>
on an API level you can't link SPIR-Vs I think
<karolherbst>
or well...
<karolherbst>
it's not defined I think
<karolherbst>
but yeah..
<karolherbst>
I think technically people could use it for this
<alyssa>
OpenCL C to NIR compiler :frog:
<karolherbst>
don't tempt me
<alyssa>
~~how hard can it be~~ Delet
<karolherbst>
I mean... at least the problem of figuring out the function prototype is simpler in a spirv llvm target as in theory you can kinda fetch the information from the clang context or something?
<karolherbst>
I dunno
<karolherbst>
I should talk with them about it...
<karolherbst>
file a bug and complain that it totally can't compile opencl c with external functions
<karolherbst>
but maybe it works better on main...
<daniels>
karolherbst, MrCooper: every single KMS user is a consumer of libdrm
<karolherbst>
jenatali: I think I'm just disappointed that they don't really care about validating their spirvs....
<karolherbst>
it was already an issue with the translator
<karolherbst>
but uhhh.. *sigh*
<karolherbst>
even the one in clinfo is invalid :')
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
kts has quit [Quit: Konversation terminated!]
<tango_>
so hm apparently kernel 6.6.9 broke rusticl radeonsi on my setup, but I think the issue may be deeper since I'm getting this on dmesg: amdgpu 0000:66:00.0: amdgpu: bo 000000008744cead va 0x0800000000-0x08000001ff conflict with 0x0800000000-0x0800000002
<tango_>
question is: where should I submit the bug?
<tango_>
oh the mystery thickens. it's a conflict between rocm and rusticl. damnit
<tango_>
and initializing rusticl before rocm leads to a deadlock in rocm
<karolherbst>
funky
<tango_>
so hm what's the policy here when the proprietary driver is involved? I assume it's «we don't care, you're on your own», which is fair
<tango_>
(actually not proprietary driver, proprietary opencl platform)
<karolherbst>
well.. doesn't really matter if it's proprietary or not
<karolherbst>
sounds like a regression in the kernel
<tango_>
I guess I could spin it that way 8-D
<karolherbst>
could `git bisect` it and figure out what broke it
<karolherbst>
or just file a bug
<tango_>
let me reboot in 6.6.8 first to make sure it's the kernel, I think the system upgrade did both kernel and mesa, which is going to make it much more … interesting to debug
<tango_>
brb
<zmike>
mareko: any other brainbusters I'm supposed to review or was that the last of them
simondnnsn has joined #dri-devel
simondnnsn has quit [Remote host closed the connection]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<tango_>
karolherbst: not a kernel issue, apparently, with the new mesa it breaks the same way on both 6.6.8 and 6.6.9
<tango_>
so, should I submit the issue anyway?
heat has joined #dri-devel
krushia has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
sravn has quit []
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Remote host closed the connection]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
tursulin has quit [Ping timeout: 480 seconds]
<gfxstrand>
Ugh... Looks like I missed a ping and it's not on the scrollback. :-(
<zmike>
jenatali: it's been too long since we both were at work
<zmike>
I missed this
<jenatali>
Agreed
simondnnsn has joined #dri-devel
<jenatali>
zmike: Seems like st_QueryInternalFormat probably should handle GL_INTERNALFORMAT_SUPPORTED, check if the target is an MSAA target, and if so, check if it can be multisampled before just returning the default true
<zmike>
jenatali: I don't suppose you wanna yolo a quick hack up there for ci to run
<jenatali>
zmike: Oh cool, that also removes a ton of debug spew from this test for me
<jenatali>
Pushed a patch, time to kick CI
<zmike>
oh nice
tlwoerner_ has quit []
tlwoerner has joined #dri-devel
<mareko>
zmike: thanks, I think that's all
<zmike>
cool
<gfxstrand>
Ah, karolherbst grumbling about scratch...
<karolherbst>
scratch?
<karolherbst>
ohh that one...
<karolherbst>
gfxstrand: yeah so the tldr is, that if we are unlucky, and the CL C code does something silly (like e.g. casting random u8 arrays to higher things) we could end up with unaligned loads, even though the layout of that memory area is up to us
<karolherbst>
but that could also prevent vectorization, e.g. loading u8[8], which we could turn into a u64 load if it would be aligned properly
<gfxstrand>
Yeah
<gfxstrand>
I'm fine with aligning things higher as long as we're not breaking CL rules by doing so.
<karolherbst>
yeah... I was wondering if we want to check in lower_explicit_io what the biggest access is
<gfxstrand>
IDK if that's practical
<gfxstrand>
That's an annoying check
<karolherbst>
for scratch and shared we could just doing, but yeah...
<karolherbst>
*do it
<karolherbst>
gfxstrand: any other ideas on what to check for?
<karolherbst>
mhhh...
<karolherbst>
guess we might need to take offsets into account as well..
<karolherbst>
like what if the access is [0:1] + 2, but also 0 + [1:2] a bit later for $reasons, and we'd have to choose, but whatever we pick, it's still better than both unaligned
<karolherbst>
but anyway.. atm I'm only thinking of checking for explicit casts
<gfxstrand>
I think if we do anything, we just align the base up.
<karolherbst>
and not to consider potentical vectorization later on
<gfxstrand>
There's no point in optimizing for accessing [3:7] of an array.
<karolherbst>
mhhh
<jenatali>
Yeah, each scratch var can be aligned to 8 bytes or 16 bytes or whatever the driver's preferred alignment is instead of just aligning it based on its type
<karolherbst>
yeah.. maybe that would be easier...
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<jenatali>
zmike: Nope apparently my missing 'break' that non-MSVC build tools told me about just broke the test... let's try again...
<zmike>
it's okay, first days back from vacation
<zmike>
shake it off
<jenatali>
O.o why does st_QuerySamplesForFormat always return one of the max-samples values...? That seems wrong
<jenatali>
zmike: Does that MR make any sense to you?
<zmike>
🤕
<CounterPillow>
People are still using NVIDIA Tesla generation boards? As in 8800GT and friends? :D
<zmike>
I think this is because in GL there's that weird thing where samplecounts aren't format specific...if you advertise a sample count you're advertising it for ALL samples
<zmike>
I remember running into something stupid like this a few years back
<jenatali>
Ok, but what if some formats can't be MSAA?
<zmike>
I think that was the stupid part where like 9E5 was still required to return support or something
<karolherbst>
CounterPillow: even the gen before tesla
<jenatali>
The more I learn about GL the more I think it was a mistake
<zmike>
hey
<zmike>
you might be right but I can't say that
<gfxstrand>
I mean, so was D3D9 and D3D8 and 11 and Vulkan and...
<gfxstrand>
Really, computers were a mistake
<jenatali>
Heh
<karolherbst>
don't worry, your secrets are safe with us
<zmike>
that we can all agree with
<zmike>
sand was not meant to think.
<CounterPillow>
OpenGL had the unpleasant role of developing in parallel with GPUs becoming generally programmable parallel processors, so I do not fault it for getting it wrong occasionally.
<jenatali>
Ok so if you ask for sample counts for 999e5 we need to return whatever the max sample count is... but I can still claim it's unsupported for a multisample target, right?
<zmike>
🤕
<zmike>
maybe
<jenatali>
sigh
<karolherbst>
well.. gl doesn't have such queries anyway, no?
<zmike>
ackchuahlly
<karolherbst>
just report more and don't do MSAA, what's the user going to do? file a bug?
<zmike>
ohhhh it was that easy all along?
<jenatali>
D3D doesn't support 999e5 as render target at all
<jenatali>
Well, not yet anyway. It's actually being added coincidentally
sima has quit [Ping timeout: 480 seconds]
<jenatali>
Maybe the answer is just add the xfails and they'll go away when that lights up and I don't care about this weird corner case on drivers that don't support it
<gfxstrand>
Why are we doing MSAA on 999e5?!?
<zmike>
that's the fun part
<zmike>
we're not
<karolherbst>
wasn't that also this part of time where people were like "look, I know our GPU doesn't support this feature, but we can emulate it really fast using LLVM"
<CounterPillow>
that sounds like Intel GMA950
<alyssa>
CounterPillow: "occassionally"
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<alyssa>
karolherbst: I've spent the past 3 years seeing if it's possible to do gl4.6 on a broken gles3.1 part (~:
<CounterPillow>
no bully the bifrost
<alyssa>
CounterPillow: actually I was talking about agx (-:
<CounterPillow>
oh, oof
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<jenatali>
Alright let's see if piglit complains about this
jeeeun841351908 has quit []
<karolherbst>
alyssa: I mean... the alternative would be to invent your own API everybody has to use to use modern but supported features of your GPU :P
<mareko>
jenatali: 999e5 wasn't renderable until RDNA 2
<jenatali>
Then I guess I don't understand why radeonsi isn't impacted by this change 🤷
<mareko>
also image stores didn't work with it either
<jenatali>
Right
<jenatali>
mareko: What happens if you ask to allocate a 999e5 multisampled texture in radeonsi prior to RDNA2? Do you still allocate it as multisampled even though you can't render to it?
<jenatali>
If so, how do you put contents in it? Blit?
<mareko>
not blittable either
<mareko>
need to reinterpret the format to uint for blits
<mareko>
I have no clue, maybe it's just untested?
<mareko>
for FBOs, we definitely report unsupported for the FBO status
<jenatali>
arb_internalformat_query2-image-format-compatibility-type tries to create multisampled 999e5
<jenatali>
It just creates it so that it can query properties against it though
jhli has quit [Remote host closed the connection]
<mareko>
it looks like we allocate it
<jenatali>
And I guess it's just zeroed or whatever since there's no way to put contents in it
<mareko>
but there is no way to set any of the pixels