zamundaaa[m] has quit [Remote host closed the connection]
JosExpsito[m] has quit [Remote host closed the connection]
doras has quit [Remote host closed the connection]
martijnbraam has quit [Write error: connection closed]
jenatali has quit [Write error: connection closed]
hasebastian[m] has quit [Write error: connection closed]
PiGLDN[m] has quit [Write error: connection closed]
DavidHeidelberg[m] has quit [Write error: connection closed]
michael5050[m] has quit [Write error: connection closed]
Newbyte has quit [Write error: connection closed]
sjfricke[m] has quit [Write error: connection closed]
mairacanal[m] has quit [Write error: connection closed]
pac85[m] has quit [Write error: connection closed]
knr has quit [Write error: connection closed]
sigmoidfunc[m] has quit [Write error: connection closed]
naheemsays[m] has quit [Write error: connection closed]
robertfoss[m] has quit [Write error: connection closed]
masush5[m] has quit [Write error: connection closed]
RAOF has quit [Write error: connection closed]
undvasistas[m] has quit [Write error: connection closed]
gdevi has quit [Write error: connection closed]
dcbaker has quit [Write error: connection closed]
reactormonk[m] has quit [Write error: connection closed]
tomba has quit [Write error: connection closed]
GeorgesStavracasfeaneron[m] has quit [Write error: connection closed]
Anson[m] has quit [Write error: connection closed]
frytaped has quit [Write error: connection closed]
egalli has quit [Remote host closed the connection]
neobrain[m] has quit [Remote host closed the connection]
Strit[m] has quit [Write error: connection closed]
pushqrdx[m] has quit [Write error: connection closed]
Jean[m]1 has quit [Write error: connection closed]
zzoon_holidays_until_3rd_Oct[m has quit [Write error: connection closed]
znullptr[m] has quit [Write error: connection closed]
DemiMarie has quit [Write error: connection closed]
aura[m] has quit [Write error: connection closed]
Andy[m] has quit [Write error: connection closed]
ella-0[m] has quit [Write error: connection closed]
Labnan[m] has quit [Write error: connection closed]
kunal10710[m] has quit [Write error: connection closed]
kusma has quit [Write error: connection closed]
jasuarez has quit [Write error: connection closed]
DrNick has quit [Write error: connection closed]
danylo has quit [Write error: connection closed]
Vin[m] has quit [Write error: connection closed]
AlexisHernndezGuzmn[m] has quit [Write error: connection closed]
Tooniis[m] has quit [Write error: connection closed]
Eighth_Doctor has quit [Remote host closed the connection]
Mershl[m] has quit [Write error: connection closed]
bluepenquin has quit [Write error: connection closed]
nielsdg has quit [Write error: connection closed]
halfline[m] has quit [Write error: connection closed]
yshui` has quit [Write error: connection closed]
heftig has quit [Write error: connection closed]
onox[m] has quit [Write error: connection closed]
nyorain[m] has quit [Write error: connection closed]
enick_11 has quit [Write error: connection closed]
jekstrand[m] has quit [Write error: connection closed]
cwfitzgerald[m] has quit [Write error: connection closed]
kunal_10185[m] has quit [Write error: connection closed]
ralf1307[theythem][m] has quit [Write error: connection closed]
viciouss[m] has quit [Write error: connection closed]
r[m] has quit [Write error: connection closed]
kallisti5[m] has quit [Write error: connection closed]
YaLTeR[m] has quit [Write error: connection closed]
eyearesee has quit [Write error: connection closed]
x512[m] has quit [Write error: connection closed]
T_UNIX has quit [Write error: connection closed]
Ella[m] has quit [Write error: connection closed]
Dylanger has quit [Write error: connection closed]
Sumera[m] has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
gagallo7[m] has quit [Write error: connection closed]
robertmader[m] has quit [Write error: connection closed]
xerpi[m] has quit [Write error: connection closed]
dos1 has quit [Max SendQ exceeded]
tleydxdy has quit [Write error: connection closed]
Mis012[m] has quit [Write error: connection closed]
moben[m] has quit [Write error: connection closed]
Soroush has quit [Write error: connection closed]
kunal_1072002[m] has quit [Write error: connection closed]
ramacassis[m] has quit [Write error: connection closed]
KunalAgarwal[m][m] has quit [Write error: connection closed]
Weiss-Fder[m] has quit [Write error: connection closed]
Wallbraker[m] has quit [Write error: connection closed]
dos11 has joined #dri-devel
tzimmermann has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
srslypascal has joined #dri-devel
fab has quit [Quit: fab]
zaratustra has quit [Ping timeout: 480 seconds]
Wallbraker[m] has joined #dri-devel
<emersion>
Lyude: the DP-MST connector removal is buggy. right now the connector is immediately marked as UNREGISTERED, then user-space disables it, then it's somehow cleaned up without sending a uevent
<emersion>
so we need to (1) decide whether it makes sense to mark as UNREGISTERED even though we still want to expose it to user-space (2) send the uevent
rasterman has joined #dri-devel
fab has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
tursulin has joined #dri-devel
djbw has quit [Remote host closed the connection]
Major_Biscuit has joined #dri-devel
ahajda_ has quit [Read error: Connection reset by peer]
ahajda_ has joined #dri-devel
MajorBiscuit has joined #dri-devel
vliaskov has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
jkrzyszt_ has joined #dri-devel
<jadahl>
emersion: thanks for mailing sasha about the patch
lynxeye has joined #dri-devel
<jadahl>
emersion: Lyude mentioned something about reference counted connectors somewhere, that might help
<emersion>
yeah i'm not sure what the procedure is
<jadahl>
same here
<emersion>
the ref'count is what keeps the connector alive yes
<emersion>
and it's tricky to send a uevent when the ref'count goes to zero
<jadahl>
i see
<jadahl>
if it can't make that happen in direct response, do we need some other thing to "poll" some how?
apinheiro has joined #dri-devel
<emersion>
we should definitely fix it in the kernel somehow
mattst88_ has joined #dri-devel
mattst88 has quit [Ping timeout: 480 seconds]
<jadahl>
i mean "thing" as in some thing that owns the connectors in the kernel looking at the list of non-freed one
pcercuei has joined #dri-devel
<emersion>
ah
<emersion>
we could look post-commit at newly disabled connectors in the UNREGISTERED state maybe
<jadahl>
something like that, or an idle callback like thing queued by things that unref connectors
genpaku has quit [Remote host closed the connection]
genpaku has joined #dri-devel
arisu has joined #dri-devel
Andy[m] has joined #dri-devel
aura[m] has joined #dri-devel
bluepqnuin has joined #dri-devel
bylaws has joined #dri-devel
chema has joined #dri-devel
RAOF has joined #dri-devel
cleverca22[m] has joined #dri-devel
cmeissl[m] has joined #dri-devel
Eighth_Doctor has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dafna33[m] has joined #dri-devel
dcbaker has joined #dri-devel
DemiMarieObenour[m] has joined #dri-devel
Anson[m] has joined #dri-devel
Guest3020 has joined #dri-devel
doras has joined #dri-devel
danylo has joined #dri-devel
Dylanger has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
Ella[m] has joined #dri-devel
AlexisHernndezGuzmn[m] has joined #dri-devel
GeorgesStavracasfeaneron[m] has joined #dri-devel
frytaped[m] has joined #dri-devel
gallo[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
frytaped has joined #dri-devel
halfline[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
hch12907 has joined #dri-devel
heftig has joined #dri-devel
zzoon[m] has joined #dri-devel
jasuarez has joined #dri-devel
Jean[m]1 has joined #dri-devel
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kunal10710[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
kunal_1072002[m] has joined #dri-devel
KunalAgarwal[m][m] has joined #dri-devel
kusma has joined #dri-devel
Labnan[m] has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
masush5[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
michael5050[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
mripard has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
eyearesee has joined #dri-devel
nielsdg has joined #dri-devel
nyorain[m] has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
onox[m] has joined #dri-devel
pac85[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
r[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
robertfoss[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
sjfricke[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
knr has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
underpantsgnome[m] has joined #dri-devel
tleydxdy has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
Soroush has joined #dri-devel
viciouss[m] has joined #dri-devel
MatrixTravelerbot[m]1 has joined #dri-devel
Weiss-Fder[m] has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
pmoreau is now known as Guest3049
swalker__ has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest3057
swalker__ has quit [Read error: Connection reset by peer]
sarahwalker has joined #dri-devel
Guest3057 has quit [Remote host closed the connection]
swalker__ has joined #dri-devel
kts has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
fahien has quit [Quit: fahien]
khfeng has quit [Ping timeout: 480 seconds]
sdutt has quit [Read error: Connection reset by peer]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
swalker__ has quit [Remote host closed the connection]
chipxxx has joined #dri-devel
swalker__ has joined #dri-devel
zaratustra has joined #dri-devel
apinheiro has quit [Quit: Leaving]
vliaskov has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
vliaskov has joined #dri-devel
kts has quit [Quit: Leaving]
kts has joined #dri-devel
kts has quit [Quit: Leaving]
shsrfud has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
shsrfud has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
kem has joined #dri-devel
fahien has joined #dri-devel
fahien has quit []
ccr has quit [Quit: leaving]
ccr has joined #dri-devel
kode54 has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined #dri-devel
jkrzyszt_ has quit [Remote host closed the connection]
bluepqnuin is now known as bluepenquin
aravind has quit [Ping timeout: 480 seconds]
bluepenquin has quit [Quit: issued !quit command]
bluepenquin has joined #dri-devel
illwieckz has quit [Quit: I'll be back!]
illwieckz has joined #dri-devel
Company has quit [Quit: Leaving]
lemonzest has joined #dri-devel
apinheiro has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
camus has quit []
kts has quit [Quit: Leaving]
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
sdutt has joined #dri-devel
fab has quit [Quit: fab]
fxkamd has joined #dri-devel
kts has joined #dri-devel
Haaninjo has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
fahien has joined #dri-devel
fahien has quit []
rasterman has quit [Quit: Gettin' stinky!]
kts has quit [Ping timeout: 480 seconds]
zehortigoza has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
djbw has joined #dri-devel
Duke`` has joined #dri-devel
aravind has joined #dri-devel
fab has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
fxkamd has quit []
fxkamd has joined #dri-devel
Leopold has joined #dri-devel
luc4 has joined #dri-devel
swalker__ has quit [Remote host closed the connection]
mbrost has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
evadot_ has quit [Remote host closed the connection]
lygstate has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
evadot has joined #dri-devel
kts has joined #dri-devel
evadot has quit [Read error: Connection reset by peer]
evadot has joined #dri-devel
rasterman has joined #dri-devel
<emersion>
does anyone know the difference between u_vector and dynarray?
<karolherbst>
dynarray uses ralloc?
<emersion>
what is ralloc?
<karolherbst>
a better memory allocator than malloc/free
<karolherbst>
it's pooled and frees trees of objects in one go.. not sure what's the proper term here
<karolherbst>
it's the thing you want to use if you do a lot of allocations and frees
<emersion>
it seems like it uses ralloc only when mem_ctx != NULL
<emersion>
i don't really care about ralloc, which one should i use?
<karolherbst>
I'd probably go with dynarray as it's used more often
<emersion>
okay
<Lyude>
jadahl: it was an idea that someone had at valve yeah
<Lyude>
emersion: huh, is it a regression or has this been happening for a while
<emersion>
hm, so
<emersion>
my patch triggers a regression on mutter
<emersion>
but the UNREGISTERED and no uevent issue, has been happening forever as far as i can tell
<emersion>
it seems like UNREGISTERED never did what it says in the docs
<Lyude>
oh no :(
<Lyude>
emersion: well if it's just sending a hotplug when the connector is removed that should be easy
<Lyude>
erm, uevent
<emersion>
Lyude: send uevent in drm_connector_cleanup()?
<emersion>
i can send that patch, and jadahl can probably test it to check it fixes mutter
<Lyude>
emersion: sgtm
<emersion>
(i'll check my compositor)
<jadahl>
this is for 6.1 right?
<jadahl>
for the stable branches we'll revert or whats the plan?
<emersion>
i think both could go to stable tress
<emersion>
revert and fix
<Lyude>
yeah that seems fine to me
<jadahl>
ah, sure. won't test until monday probably though
<emersion>
no rush
<Lyude>
emersion: we might also want to consider maybe doing it in the mst connector cleanup?
<jadahl>
the rush I have is to not end up regressing on stable trees if we don't fix things :P
<Lyude>
instead of drm_connector_cleanup(), since I think we're basically the only connector type that can disappear
<Lyude>
jadahl: no that's totally fair lol
<emersion>
hm, yeah, that might be safer
<Lyude>
tbh I'm surprised I thought we already did this. it is worth noting I'm pretty sure if multiple connectors are dropped sequentially we only send a single uevent once we've finished removing them
<emersion>
Lyude: hm i think this won't work, drm_dp_delayed_destroy_port() unlinks the connector
<emersion>
so we don't know when the last ref is dropped
nchery has joined #dri-devel
<Lyude>
ahh, there should be a function we can use for that. check the callbacks for get/put. the other thing is too that we do need to be careful when we send uevents (e.g. making sure we don't try to do something with fbcon at the wrong spot which might lead us to trying to do an atomic commit iirc?)
nchery_ has joined #dri-devel
nchery is now known as Guest3107
nchery_ is now known as nchery
ybogdano has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
<emersion>
Lyude: hm which callback? i don't see any callbacks in kref/drm_mode_object/drm_connector
<illwieckz>
I managed to set up an environment that can build Mesa 21 and LLVM 11, and I identified two commits from the same branch that both build LLVM and use that LLVM to build the same Mesa while one commit does not reproduce the bug and another one does.
<illwieckz>
9601 revisions to go. 😅️
<karolherbst>
oh 2o2
<karolherbst>
*wow
<illwieckz>
and on every step, llvm is entirely rebuilt 😱️
<illwieckz>
burn, cpu, burn!
<karolherbst>
it will only take a week!
<jadahl>
emersion: isn't "drm_connector_free" the callback?
<Lyude>
emersion: wrong one, one sec
* Lyude
open up nvim
<emersion>
"cleanup"
<illwieckz>
in fact it saids it's about 13 steps, but I'm unlucky because on second step it said 13 steps again 😆️
<Lyude>
emersion: hm. so wait-when you say "don't know when the last ref is dropped" are you talking about the mst topology refs or the actual DRM object references
<emersion>
drm_connector_cleanup() is called when the last ref is dropped
<emersion>
but i assumed it would be bad taste to just fire off a uevent in that
<emersion>
if it's fine, everything is simple
<emersion>
i would've been less worried to fire off the uevent explciitly when user-space disables an UNREGISTERED connector
<emersion>
(UNREGISTERED should really be called UNREGISTERING)
<Lyude>
emersion: I guess I'm just confused why drm_dp_delayed_destroy_port() wouldn't work?
<emersion>
Lyude: it unregisters the connector, but user-space hasn't disabled the connector at that point
<emersion>
it's still linked to the CRTC at that point
<emersion>
so it lingers for a bit longer
<Lyude>
emersion: ooh, that's still supposed to work though (like-connectors should always be safe to disable even if unregistered, so if we're rejecting a commit to disable a unregistered connector that's a bug in itself)
<emersion>
yup, that works fine
<jadahl>
Lyude: the problem is we don't get the uevent
<jadahl>
after it was disabled
<emersion>
^
<emersion>
so from user-space PoV the connector still exists
<jadahl>
so it'll be there, but not, so when we disable it again for whatever reason, it's not there anyomore, and te commit fails
<emersion>
IOW, user-space's view of KMS state is outdated
<Lyude>
we really shouldn't be failing any commit for a connector that's dropped, but it sounds like it's just not sending the hotplug at all. looking at drm_dp_delayed_destroy_work we definitely should be sending a uevent once we finish dropping connectors that got dropped from the topology
<jadahl>
Lyude: we send the first hotplug, but not the one after the commit that disables the already gone connector
kem has quit [Ping timeout: 480 seconds]
<emersion>
it should go like this:
<Lyude>
jadahl: oooooh ok. okokok that makes much more sense :)
* emersion
saves his saliva
<jadahl>
if drm_dp_mst_topology.c could get told that a delayed connector lost its last ref, it could send an uevent at that point maybe?
<Lyude>
yeah I guess that is completely missing and not something I realized we'd need. jadahl: so if the issue is you want to know the connector is gone once you disabled it, I think our best bet would be to just check in the kernel after a commit whether any connectors in the commit that got disabled are unregistred and if so, send a uevent
<jadahl>
that was one idea emersion mentioned earlier IIRC
<jadahl>
and it'd probably work too
<emersion>
i wanted to add the uevent to drm_connector_unregister
<emersion>
but it's too soon
<jadahl>
oh, thought you mentioned post-commit check-if-gone too
<emersion>
yeah, that too
alyssa has joined #dri-devel
<alyssa>
zmike: we should delete more caps
<emersion>
this could work with an old->enabled && !new->enabled && state == UNREGISTERED
<Lyude>
emersion: i guess actually both of those are probably fine then now thta i've looked at it a bit. the one thing we might want to do just to be nice is to avoid sending a hotplug event in the drm_connector_cleanup() case if we're unregistering the drm device
<emersion>
but we would send the uevent _just_ a bit too early
<Lyude>
but other then that it should work fine
<emersion>
Lyude: is there a nice way to say if (device is unregistering)
<emersion>
?
<Lyude>
emersion: there should be in drm iirc, let me see if I can find it
<emersion>
dev->registered?
<emersion>
oh, dev->unplugged exists too
<zmike>
alyssa: PIPE_CAP_DELETED
<Lyude>
emersion: yeah registered should be the right one
<emersion>
and drm_dev_is_unplugged()
<Lyude>
emersion: unsure if that'll catch it if it's say, a module being unloaded. iirc that's more for actual hotplugging where we need to know a device literally isn't accessible after being removed
<Lyude>
registered I think is the correct one
<emersion>
okay
<Lyude>
although, to be honest maybe we can just skip that check for now
<Lyude>
and just see if anyone complains about the compositor trying to do things during module unload, but i'm realizing that's probably not that likely of a scenario so it's fine
<Lyude>
i guess one thing i'd make sure to do: do some hotplug testing with any changes like that using other connectors with a lockdep enabled kernel, just to make sure we don't hit any weird locking issues as a result of this
RSpliet has quit [Quit: Bye bye man, bye bye]
kem has joined #dri-devel
RSpliet has joined #dri-devel
agners has quit [Quit: WeeChat 3.6]
<alyssa>
zmike: i'm deleting a CAP wish me luck
<alyssa>
oh uh maybe I can't actually delete this CAP
<alyssa>
very sad
kode54 has joined #dri-devel
kode54 has quit []
kode54 has joined #dri-devel
<alyssa>
darn nv30 and buggy virglrenderer
<karolherbst>
using that cap?
<alyssa>
failing to support the cap
<alyssa>
!19079
iive has joined #dri-devel
<karolherbst>
mhh
<karolherbst>
not knowing about the hardware enough, but I suspect the hw really can't support it
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<alyssa>
bluh
<alyssa>
another CAP is supported by "everyone but nv30 and lima"
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
<karolherbst>
nv30 is the gift which keeps giving
<Frogging101>
So this is why I haven't been able to scroll my tty
<alyssa>
tango_: Mesa can only use Khronos trademarks for standards that Mesa is conformant on
<karolherbst>
guess we'll wait 29 days
<tango_>
alyssa: ah
<alyssa>
Despite Rusticl+Iris passing the OpenCL CTS, it's not conformant until Khronos says so
<karolherbst>
I think the rule is: wait 30 days
<zmike>
there's a review process
<tango_>
alyssa: oh nice. so we'll have opencl support for intel on mesa “soon”?
<karolherbst>
zmike: yeah, and I filed for conformance yesterday
<zmike>
a big step
<karolherbst>
huge one
<zmike>
massive
<karolherbst>
we can use the logo then!
<tango_>
wait, iris?
<karolherbst>
sure
<tango_>
the discrete one?
<karolherbst>
no
<karolherbst>
though it should work as well
<karolherbst>
probably
<karolherbst>
people wanted to try it or something
<karolherbst>
there was a vote and now people want to see it being conformant on radv
* tango_
goes to look which gen is irisi
<zmike>
is zink going to be opencl conformant before opengl? 😬
<karolherbst>
would be a weird flex
<alyssa>
karolherbst: How is variable_shared_mem supposed to work with zink/vulkan?
<karolherbst>
alyssa: in a crappy way?
<zmike>
I made it a runtime array
<zmike>
seemed to work
<karolherbst>
yeah.. as long as the compilation happens at launch time, it works
<karolherbst>
though...
<karolherbst>
or maybe some drivers just don't care
<karolherbst>
there are a lot of CTS fails I still need to dig through
<zmike>
did you ever figure out that image copy thing
<zmike>
that was a weird one
<karolherbst>
didn't had a chance to look yet
<tango_>
if I happen to get a student interested in this, are there low hanging fruits they could tackle?
<karolherbst>
busy landing a few other patches we need and my machine was busy crunching through the CTS
<karolherbst>
(which runs for a _long_ time)
<karolherbst>
tango_: API validation probably
<karolherbst>
and writing tests for them in the CTS
<tango_>
the CTS doesn't cover the full API?
<karolherbst>
it's all rust code, so people would need to get familar anyway
<karolherbst>
tango_: heh.. nope
<tango_>
oh wow lol
<karolherbst>
well.. it does check features
<karolherbst>
it just doesn't care much about errors
<karolherbst>
khronos is open to add tests for that though
<tango_>
that might explain why some theoretically conformant implementations do stupid things (me eyes nvidia and their acceptance of int4 = float4 assignments without convert_)
<karolherbst>
inside ruticl/api/*.rs there are tons of comments describing errors at the end of function bodies
<karolherbst>
thore are all todos
<zmike>
I'd still like to see an enum for the frontend that could be passed to screen create
<karolherbst>
tango_: ehh.. that's compiler stuff
<zmike>
I really don't want to be enabling huge sampler arrays in GL
<karolherbst>
and opencl C is literally C
<tango_>
karolherbst: shouldn't that be checked by the CTS too?
<karolherbst>
it's legal in C?
Leopold has quit [Remote host closed the connection]
<karolherbst>
or isn't it?
<tango_>
karolherbst: pretty sure the opencl c spec forbits assignment of float4 to int4 and vice-versa
jagan_ has joined #dri-devel
<karolherbst>
mhhh...
<karolherbst>
guess it should be checked then?
<tango_>
karolherbst: in general for vector types. scalar yes
<tango_>
(as in C)
<tango_>
let me double-check the spec
<karolherbst>
anyway... I think people would be happy to add those tests
<karolherbst>
zmike: ahh yeah, I'll add that once I continue working on it (next week)
<karolherbst>
zmike: I really want to land 18581 btw, in case you are bored and want to review gallium API changes :P
<zmike>
uhhhh
<karolherbst>
it's the MR dropping launch_grid_info.input as well
<tango_>
karolherbst: > Implicit conversions between built-in vector data types are disallowed. < (6.4.1)
Leopold_ has joined #dri-devel
<karolherbst>
and uses cb0 for the input instead of that
<karolherbst>
so I kind of want to get it in for zink as well
<tango_>
so, how do you submit tests to the CTS? 8-D
<karolherbst>
tango_: you'll create a PR on github
<tango_>
ah ok, simple
<karolherbst>
yeah
<karolherbst>
and it's discsussed on the OpenCL working group meeting, which I started to attend
alyssa has left #dri-devel [#dri-devel]
<zmike>
karolherbst: I got in there
tzimmermann has quit [Quit: Leaving]
Leopold_ has quit [Remote host closed the connection]
<karolherbst>
uhhh... that's probably the reason I don't want to :D
<illwieckz>
to summarize: luxmark requires qt4, qt4 requires gcc7 or less to be built, gcc7 requires gcc10 or less to be built
<karolherbst>
yeah.. sounds like pain
<illwieckz>
that's why I fully scripted it 🤣️
<karolherbst>
yo, but I don't have gcc-10
<karolherbst>
12.2.1 here
<illwieckz>
I can make the script build gcc10 🤣️
<karolherbst>
please don't
<illwieckz>
luxcore also requires gcc10 so even if someone manages to port luxmark3 to qt5, gcc10 would still be needed
<illwieckz>
I believe in my early attempts my script compiled two gcc
<illwieckz>
until I figure out 10 was able to build 7
<illwieckz>
and 10 was still available in Ubuntu
Company has joined #dri-devel
<illwieckz>
I probably had the script built gcc8 or 9 to build gcc7
<illwieckz>
building old software can be hard
<illwieckz>
especially compilers
<illwieckz>
as old compilers were built with older compilers, not newers
<jenatali>
What happens if you try to use a newer compiler?
<illwieckz>
many errors I'm don't have knowledge to understand
<illwieckz>
and I have patched many
<karolherbst>
C compilers started to disallow stupid but legit code
<illwieckz>
for example when building qt4, using a newer compiler the compiler just errors saying stuff are not defined
<illwieckz>
like this members of this class doesn't exist
<illwieckz>
no other message
<karolherbst>
heh...
<karolherbst>
might be a c++ std thing
<illwieckz>
probably
<karolherbst>
like might have to force c++89 or something
<illwieckz>
I'll have to check
<karolherbst>
ehhh 98
<karolherbst>
at some point compilers moved also to the new ABI
<illwieckz>
I'm not sure c++89 existed :D
<karolherbst>
it's the secret version before it become a feature creep
<illwieckz>
oh damn, Lattice C was released on 1982, it means it's 40 years old
<illwieckz>
(that was my first compiler)
<karolherbst>
yeah.. C is a little old
<illwieckz>
(I'm not as old as Lattice C if you are wondering 🙃️)
<karolherbst>
me neither
<karolherbst>
though I think the first time I actually touched C was when I started to hack on nouveau stuff
<illwieckz>
I still have it anyway, and it runs
<karolherbst>
not caring much about performance at this point anyway. It's just funny that performance in rusticl isn't terrible... but then again, why would it
<jenatali>
karolherbst: What do you do about fma?
<karolherbst>
it's still emulated?
<jenatali>
Ah ok, that's I think where all of the perf problems I've heard of come from
<illwieckz>
the first C program I wrote with my dad was a program to compute pi with lattice C
<karolherbst>
jenatali: sure.. but I doubt luxmark uses fma, because if it would, that would make it all even funnier
<karolherbst>
but which perf problems do you mean?
<jenatali>
The emulation for fma is HUGE
<karolherbst>
yeah.. I know
<karolherbst>
and we should fix it
<karolherbst>
we should add ffma + fmad to nir, but the bikeshedding...
<jenatali>
Yeah
<jenatali>
And even if you did I'd still have to use the emulation because DXIL doesn't have a 32-bit fma instruction...
<karolherbst>
it's easy to fix, it's hard to land
<karolherbst>
...
<karolherbst>
gross
<jenatali>
Yep
<karolherbst>
having both is the only sane solution
luc4 has quit [Remote host closed the connection]
<jenatali>
Agreed
Leopold_ has joined #dri-devel
<alyssa>
jenatali: why does DXIL not have fma
<alyssa>
that sounds wrong
<karolherbst>
bikeshedding
lynxeye has quit [Quit: Leaving.]
<karolherbst>
glsl doesn't have fma either :P
<jenatali>
Yeah that was going to be my answer
<jenatali>
It wasn't part of 3D APIs really
<karolherbst>
yeah.. having real ffma in 3D makes no sense
<jenatali>
It has a 64-bit fma though for whatever reason...
<karolherbst>
ohh right....
<karolherbst>
the fun part is a precise fma is actually _never_ an fma.. it's all so absurd
<karolherbst>
ehh wait
<karolherbst>
that statement is wrong
<alyssa>
karolherbst: disagree
<alyssa>
GLSL's lack of real ffma was a mistake imho
<karolherbst>
it is
<karolherbst>
but you also don't want to lower it on hardware not having it
<karolherbst>
though there could have been fmad and ffma, but then nobody would have used ffma, because it can be terribly slow
<alyssa>
only on bad hardware
<alyssa>
like midgard ;p
<karolherbst>
right.. but from an API perspective I can see why there is only one choice really.. well.. there are two, but...
<jenatali>
D3D has a fmad instruction and documents that it's allowed to fused if the driver wants, as long as it's no worse performance than unfused
<karolherbst>
could have added a GL_WANT_REAL_FMA_FOR_REAL flag
<alyssa>
ah
rasterman has quit [Quit: Gettin' stinky!]
orbea has quit [Remote host closed the connection]
orbea has joined #dri-devel
jernej has quit [Read error: Connection reset by peer]
apinheiro has joined #dri-devel
jernej has joined #dri-devel
jernej_ has joined #dri-devel
fab has quit [Quit: fab]
Haaninjo has quit [Quit: Ex-Chat]
apinheiro has quit [Quit: Leaving]
<karolherbst>
zmike: huh.. didn't we fix local (real name: shared) memory in zink?
<zmike>
uh
<karolherbst>
the ./build/test_conformance/atomics/test_atomics tests?
<zmike>
those were passing at one point, yes
<karolherbst>
maybe I messed up rebasing something...
<zmike>
did you pull my cl branch?
<karolherbst>
probably
<zmike>
I think I already landed some of it
<karolherbst>
what's the latest?
<zmike>
idk
<zmike>
I haven't done anything since I was sitting next to you
<karolherbst>
yeah.. then I probably pulled it all
<karolherbst>
I'll figure it out...
jfalempe_ has quit []
<karolherbst>
ahh found it...
<karolherbst>
my variable_shared_mem stuff is missing
<zmike>
all I know is my cl branch was passing it
<karolherbst>
okay.. will take a look
<zmike>
I think probably it was just working because variable size = runtime array in spirv
<zmike>
none of the shared_mem from the compute state is used by zink
<karolherbst>
yeah...
<zmike>
it's all from the shader
<karolherbst>
trying your branch and see if I can figure something out
<karolherbst>
yeah.. it passes with your branch
<zmike>
💪
<karolherbst>
ohh there are a few commits I don't have :) oops
<karolherbst>
ehh.. the others don't matter.. guess I messed up rebasing
chipxxx has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
<karolherbst>
okay.. I have a rebase which works
vliaskov has quit [Remote host closed the connection]
chipxxx has joined #dri-devel
ahajda_ has quit []
<karolherbst>
k... now I finally rebased without screwing up!
alyssa has left #dri-devel [#dri-devel]
mbrost has joined #dri-devel
<karolherbst>
yay.. luxmark still crashing but at least it renders something right for a short moment
<karolherbst>
actually.. I messed up again :(
iive has quit [Quit: They came for me...]
<illwieckz>
karolherbst, I tried building qt4 for luxmark with gcc10 directly using -std 98 or 11… it doesn't build =)
<karolherbst>
zmike: heh.. seems like we messed up and it's also broken on your branch, just radeonsi was picked up instead
<zmike>
🤔
<karolherbst>
the global atomic stuff does work though...
<karolherbst>
I just need to figure out how to pass the variable shared mem through and I suspect this will fix it.. though I already _hate_ this part as I don't think vulkan has a good solution for that here
<zmike>
so the runtime array thing wasn't actually working?
<karolherbst>
looks like it
<zmike>
hm
<zmike>
could probably spec constant the size then
<karolherbst>
mhhhh
<karolherbst>
if it works like that
<zmike>
either that or just do full pipeline variants
<zmike>
I think I had code for that already somewhere
<zmike>
or maybe it was something else
<karolherbst>
guess spec constants are probably easier, though are vulkan drivers actually doing something different then full recompiles?
<zmike>
> implementation detail
<zmike>
so yeah, probably set up a spec constant for the size of the array if the size is variable and then fill it in and do variants
<zmike>
seems stupid though
mbrost has quit [Ping timeout: 480 seconds]
<zmike>
there's already an example of it in zink_pipeline.c, so you'd just want to change that up to work for KERNEL stage pipelines
<zmike>
assuming it's legal to make the shared array size a spec constant anyway
mbrost has joined #dri-devel
<karolherbst>
yeah..... though it might be legal
<karolherbst>
not sure vulkan really cares as it's mostly just affecting amount of threads available
<karolherbst>
though there is odd hardware where it even affects RA