ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<airlied>
mareko: fyi seeing a terminal cursor lag/misrendering in gnome-terminal under gnome-shell/wayland when I update to 22.3.0-rc2/3/4, I'll see if I can figure out how to bisect
<airlied>
mareko: disabling glthread for gnome-shell seems to fix it
<airlied>
mareko: and yes I have the st/mesa fix you landed
pcercuei has quit [Quit: dodo]
<airlied>
mareko: filed 7775
<alyssa>
If there is a PIPE_FORMAT_RG32UI vertex buffer, and the vertex shader reads it as an `ivec4`, what is in the `.w` channel?
djbw has quit [Read error: Connection reset by peer]
<alyssa>
0 or 1?
<alyssa>
Mesa claims it has PIPE_SWIZZLE_1 but I am unsure if that's correct and I'm having troubles finding the spec references for how vertex fetch is supposed to work
<alyssa>
and both 0 and 1 are passing CTS (but 0x3f800000 isn't ;) )
<alyssa>
for each GPU it has "thread count with N registers"
<alyssa>
which is the de facto maximum threads per work group if you want barriers or local memory to work
<karolherbst>
though not really looking forward in hardcoding the table.. but maybe I'll figure something out
<alyssa>
meh
<alyssa>
just return 256 for everything
<karolherbst>
ehh...
<karolherbst>
yeah well.. no :P
<alyssa>
I'm committed to not supporting cl on anything older than mali-g71 unless someone pays :-p
<jenatali>
1024 is D3D's limit
<alyssa>
jenatali: minimum-maximum?
<karolherbst>
alyssa: the idea was to expose higher thread counts if possible tho
<jenatali>
alyssa: and maximum-maximum
<jenatali>
Not driver-exposed, just specified
<alyssa>
jenatali: Lol oka
co1umbarius has joined #dri-devel
<karolherbst>
alyssa: what's up with thoes limits of G510/G310?
<karolherbst>
depending on shared mem or something?
<alyssa>
I think depending on what the SoC integrator picks
<karolherbst>
ahh
<alyssa>
IIRC there were like 5-10 variants of those that Arm sold under the same part name
<karolherbst>
k
<karolherbst>
seems like only the vec4 versions need a bit more complex rules, but still feels like aligned divisions
<karolherbst>
ehh.. maybe not
columbarius has quit [Ping timeout: 480 seconds]
<karolherbst>
the midgard ones are just plan weird..
<alyssa>
midgard makes sense except mali-t880, idk what they did there
<karolherbst>
heh. actually
<alyssa>
mali-t880 is a just a big mali-t860 and also I never managed to get any t880 hardware running linux
<karolherbst>
should just calculate with 384 and min2(result, 256)
<karolherbst>
then it all goes through the some algo
<karolherbst>
lol
<karolherbst>
I see
<alyssa>
there are 4 distinct cases architecturally
<alyssa>
v4-v5: vec4 hardware that can do full, half, or quarter
<alyssa>
(where full is 256)
<alyssa>
v6: only full 384 lol have fun
<alyssa>
(g71, g72)
<karolherbst>
granted, that table looks cursed
<alyssa>
v7: full or half, where full is 768 on the real gpus and 512 on the puny h31
<alyssa>
s/h31/g31/
<karolherbst>
but I say radeonsis way of getting that info is way more cursed :P
<alyssa>
v9: full or half, full is 1024
<alyssa>
v10 (g710,g510,g310): full or half, full depends on the model
<karolherbst>
yeah.. so we have 3 groups and one oddbal lbasically
<karolherbst>
shouldn't be too hard to support that
<alyssa>
karolherbst: keep in mind I did all the CL testing on G57 (v9) only
<alyssa>
backporting to v6 is in scope for "reasonable"
<karolherbst>
I'm sure I'll be able to press that into one algo for all 🙃
<alyssa>
doing cl on v5 and older (the vec4 hw) is a WONTFIX from me at this point, it's a completely separate ISA that shares a driver for historical reasons
<karolherbst>
I mean...
dliviu has quit [Quit: Going away]
<alyssa>
own compiler that's not CL ready
dliviu has joined #dri-devel
<karolherbst>
yeah..
<karolherbst>
I can focus on bitfrost+
<alyssa>
thanks
<alyssa>
v6/v7 and v9/v10 are different ISAs but close relatives so share a compiler
<karolherbst>
not that I plan to do anything more than implementing workgroupinfo without having the hardware anyway 🙃
<karolherbst>
imagine your thread count would depend on the fact the workgroup is variable 🙃
<alyssa>
?
<karolherbst>
did you check what I had to do for radeonsi? very cursed
<karolherbst>
anyway.. apparently their max thread count depends on the fact if the workgroup size is known at compile time or not
<karolherbst>
and shared size matters
<karolherbst>
so apparently if there is variable shared memory, I basically can just assume at least one wave can launch 🙃
<karolherbst>
(which is either 32 or 64 threadS)
<karolherbst>
anyway...
<karolherbst>
I'll imlpement the reamining stuff and see how it goes
<karolherbst>
(this might even break atomics in weird ways as it did on radeonsi)
<mareko>
airlied: an app-specific workaround disabling glthread would be desirable for this as I don't know how to trace gnome-shell/wayland
<karolherbst>
mareko: any idea why using ""workgroup" instead of "workgroup-one-as" for shared atomics would help fixing issues with atomics across multiple waves?
<karolherbst>
for the sync_scope I mean
Haaninjo has quit [Quit: Ex-Chat]
yuq825 has joined #dri-devel
lygstate has quit [Remote host closed the connection]
<alyssa>
Venemo: In hindsight sharing vertex input lowering code between AMD and AGX doesn't make any sense
<alyssa>
I just finished up the lowering [1], it's 250 LOC, about 10% of which is related to vertex inputs conceptually and the other 90% are AGX ISA-specific format munging
<airlied>
mareko: my worry is that every compositor might be broken
<mareko>
karolherbst: I'm sure llvm will have the difference documented somewhere
<karolherbst>
yeah.. just didn't make much sense tbh.. "one-as" just adds "but only synchronizes with other operations within the same address space." on top and I am a little confused on why that matters. Maybe I should do more digging...
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
Akari has joined #dri-devel
<airlied>
mareko: also happy to try and debug a bit more if you can give me any info on where it might be messing up
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<airlied>
karolherbst: did you know opencl signbit scalar return 0/1, whereas vector returns 0/-1
bmodem has joined #dri-devel
<airlied>
karolherbst: I do wonder if the clc impl is wrong here
<airlied>
but not sure where we should fix it up
tarceri has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
TMM has joined #dri-devel
TMM has quit [Ping timeout: 480 seconds]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
Znullptr has quit []
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
<mupuf>
DavidHeidelberg[m]: Yeah, I really like Alpine. I use it a lot for boot2container :) But yeah, for testing Mesa, it makes little sense.
gbelgurr has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
fxkamd has quit []
aravind has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
fab has joined #dri-devel
TMM has joined #dri-devel
aravind has joined #dri-devel
gbelgurr has joined #dri-devel
yuq825 has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
srslypascal is now known as Guest45
srslypascal has joined #dri-devel
camus has joined #dri-devel
Guest45 has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
pjakobsson has quit [Remote host closed the connection]
fab has quit [Quit: fab]
alanc has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
Major_Biscuit has joined #dri-devel
fab has joined #dri-devel
kts has joined #dri-devel
tzimmermann has joined #dri-devel
sgruszka has joined #dri-devel
rasterman has joined #dri-devel
danvet has joined #dri-devel
dcz_ has joined #dri-devel
tursulin has joined #dri-devel
aissen_ has quit []
aissen has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
vliaskov has joined #dri-devel
<kusma>
Oooh, we recentcly passed MR 20000 :)
<kusma>
(for mesa)
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
<karolherbst>
airlied: the translator maps that to SpvSignBitSet
<karolherbst>
*SpvOpSignBitSet
<karolherbst>
but anyway.. the CTS is happen
<karolherbst>
but yeah...
<karolherbst>
there are a few of thos
<karolherbst>
*those
swalker_ has joined #dri-devel
swalker_ is now known as Guest52
swalker__ has joined #dri-devel
lynxeye has joined #dri-devel
<MrCooper>
kusma: nice, wonder when we'll hit six digits :)
Guest52 has quit [Ping timeout: 480 seconds]
<kusma>
Yeah... MR numbers is starting to look like SVN revision numbers used to :(
sysescool has joined #dri-devel
linusw has joined #dri-devel
Sachiel_ has joined #dri-devel
pcercuei has joined #dri-devel
Sachiel has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
Sachiel_ is now known as Sachiel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
MrCooper has quit [Quit: Leaving]
MrCooper has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
tarceri has joined #dri-devel
srslypascal has joined #dri-devel
<airlied>
karolherbst: yeah but signbitset is a bool
<karolherbst>
right...
<airlied>
llvmpipe has 32 bit bools which means it writes -1 but scalar test expects 1
<karolherbst>
ehh...
<airlied>
just not sure where that should get fixed up
<karolherbst>
"annoying"
<karolherbst>
yeah...
<karolherbst>
probably in the translator
<karolherbst>
dunno
<karolherbst>
I really want to nack treating CL and VK spir-v differently as much as possible
<karolherbst>
we already have enough of that and it's getting annoying
<karolherbst>
the translator should just deal with it if it maps to spir-v ops
<airlied>
yeah not sure how best to do it, but not mapping to bool mightbe geet
<karolherbst>
uhh.. I just came up with a cursed idea of doing value range analysis: we insert "iand" or "min/max" instructions restricting the value range of certain loads/calculations, but mark them as "always eliminate" and then they just get cleaned up at some point...
jkrzyszt has joined #dri-devel
aissen_ has joined #dri-devel
junaid has quit [Remote host closed the connection]
aissen has quit [Ping timeout: 480 seconds]
sysescool has quit [Remote host closed the connection]
jkrzyszt has quit [Remote host closed the connection]
junaid has joined #dri-devel
Lucretia has quit [Remote host closed the connection]
Lucretia has joined #dri-devel
Akari has joined #dri-devel
kts has quit [Quit: Leaving]
Sachiel_ has joined #dri-devel
Sachiel has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
apinheiro has quit [Ping timeout: 480 seconds]
aissen_ has quit []
aissen has joined #dri-devel
yuq825 has joined #dri-devel
<mareko>
airlied: you can try to set HasExternallySharedImages = true by default
<mareko>
other than that, it's possible that some place is missing thread_finish() e.g. in frontend/dri
yuq825 has quit []
Akari has quit [Quit: segmentation fault (core dumped)]
<mareko>
karolherbst: LLVM has per-instruction metadata specifying the range
<mareko>
it's possible that many passes will destroy the metadata though
<karolherbst>
ahh.. I see
sgruszka has quit [Ping timeout: 480 seconds]
zehortigoza has quit [Remote host closed the connection]
sul has quit [Read error: Connection reset by peer]
<cwabbott>
karolherbst: that's not a new idea, LLVM considered it at one point but rejected because too many passes would have to be updated to understand/look through that the "range bound" instructions
<cwabbott>
that's why it's done as metadata, because even though you still have to update passes to thread things through, if you add metadata and passes aren't updated then at least it's not any worse than it was before
<karolherbst>
why though? the idea was, that passes checking combinations (like we already do, e.g. shifts) just make use of the "fake" instructions
<karolherbst>
and then we just remove them
<karolherbst>
but yeah, I totally get why one might want to have a better approach there
camus has quit [Ping timeout: 480 seconds]
<cwabbott>
if you "just remove them" then you can't use them anymore
<cwabbott>
and up until the point where you "just remove them" they look like an extra use, and block transforms that depend on the number of uses
<karolherbst>
sure, that's why you do another round of opts after removing them
<cwabbott>
what if you want to use them late? that's very common
<karolherbst>
but anyway, it wasn't a serious proposal anyway
<cwabbott>
can't just do another round of early opts
<karolherbst>
I'm aware of the issues 🙃
<cwabbott>
anyway, the answer here is metadata
Company has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
fab has quit [Quit: fab]
jkrzyszt has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<MrCooper>
airlied mareko: I checked that mutter has HasExternallySharedImages set, and it's hitting thread_finish during its updates (looks like before SwapBuffers though, but I don't think any drawing happens later)
fab has quit [Read error: Connection reset by peer]
fab_ has joined #dri-devel
fab_ is now known as Guest84
rmckeever has joined #dri-devel
<gawin>
thanks
JohnnyonF has quit [Read error: Connection reset by peer]
sul has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
swalker__ has quit [Remote host closed the connection]
gawin has quit [Ping timeout: 480 seconds]
<lina>
Mesa works on the Apple M2 / G14G with no changes at all from M1/G13! KDE/Xonotic/etc all working ^^
lemonzest has quit [Quit: WeeChat 3.6]
<lina>
Only the kernel side needed changes, userspace just worked. A few days ago I added some forward-looking product name generation code and set it up to gate probing on an incompat_features bitmask, so with the kernel reporting no compat breaks and the right GPU identification it all just worked, not even one line of code changed.
<alyssa>
lina: would now be a completely terrible time to let you know I'm not comfortable merging any M2-specific Mesa changes yet? ;-p
tursulin has quit [Ping timeout: 480 seconds]
<lina>
^^;;
<lina>
I guess that means no M2 macOS support for you then!
<alyssa>
sounds good :-p
<lina>
(I have no idea if/how the IOKit API changed, didn't need to go there since I only looked at the kernel side)
<alyssa>
just the thought of doing both 12.3 and 12.4 is enough to say no m2 macOS support in mesa
<alyssa>
and given how close things are I see no reason to bother?
<lina>
It *could* be they didn't break compat!
<alyssa>
lol
<lina>
It could also be they broke compat for other reasons, like they did in the kernel
<lina>
G14 12.4 kernel is a very different beast from the 12.3 -> 13.0 pipeline
<lina>
I didn't see any of the 13.0 changes introduced, instead some things were *regressed* (I guess they forked off earlier?) and some things were added (unless those were regressed removals)
<alyssa>
fun
<alyssa>
11.4 -> 12.3 was painful enough for me
<alyssa>
(for macOS uapi)
<lina>
Yeah but that was a major version, they seem to be making fewer changes for minor ones
<lina>
DCP is the same
<lina>
(that's a big one)
<alyssa>
I want to wack support macOS support from the mesa drivers it's just still way too useless
<alyssa>
and keeping 12.3-only around is pretty much "whatever"
<lina>
Oh also, I saw a new zls flag 0x1, which I thought was new but looking back through old logs it popped up on the M1 Ultra already too
<alyssa>
fun
<alyssa>
lina: also see signal i texted you uwu
<lina>
So that might have always been there or be new for G13X/G14
bluebugs has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
gawin has joined #dri-devel
<deathmist>
hey, I marked https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19263 with "Cc: mesa-stable" but it still isn't in 22.2.4, what did I do wrong? the patch unfortunately did not apply cleanly on stable but I specified how it could be adapted in the MR. should I have made an MR against some stable branch?
tzimmermann has quit [Quit: Leaving]
<kisak>
blind guess that there was a merge conflict with the CI tests and the release maintainer didn't have time to look closer.
jkrzyszt has joined #dri-devel
<deathmist>
oh well 22.3 is around the corner anyway now and I'm not on a static release distro :)
sarnex has quit [Quit: Quit]
sarnex has joined #dri-devel
<kisak>
deathmist: ah right, if a backport doesn't apply cleanly to a release branch, it's usually better to open a separate merge request against staging/XX.X and note the difference there so that it's got a bit more visibility to the release maintainer along with the explicit intent for how it should be handled.
junaid_ has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
<deathmist>
kisak: got it, will do that next time
<eric_engestrom>
indeed, I just had a look and the line modified in 09b28524 doesn't exist on 22.2
<eric_engestrom>
so I guess that's why dcbaker dropped the commit
<eric_engestrom>
ah, I just re-read your first message and I had missed the "but I specified how it could be adapted in the MR" part of your message
<eric_engestrom>
I just read what you wrote in the MR but it's unclear how the issue should be fixed? anyway, I guess you don't need the fix in 22.2.x, and if nobody else complains...