<karolherbst>
ahh.. global atomics crash the kernel, whtvr
<karolherbst>
"[15649.356404] v3d fec00000.v3d: MMU error from client L2T (0) at 0x2000, write violation, pte invalid" how rude
<karolherbst>
is it now dead or...
<karolherbst>
mhhh
<karolherbst>
rude
<karolherbst>
huh
<karolherbst>
yeah, that won't fly...
<karolherbst>
yo... something is still very wrong
paulk has quit [Read error: Connection reset by peer]
paulk-bis has joined #dri-devel
co1umbarius has joined #dri-devel
bmodem has joined #dri-devel
srslypascal has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
alyssa has left #dri-devel [#dri-devel]
pa has joined #dri-devel
cphealy has quit [Quit: Leaving]
ybogdano has joined #dri-devel
<karolherbst>
"conversions passed" :3
<karolherbst>
somehow it didn't like that I allocated 256 threads, but limiting it to 64 works.. fun
lemonzest has quit [Quit: WeeChat 3.6]
ybogdano has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
Daaanct12 has quit [Remote host closed the connection]
slattann has joined #dri-devel
Company has quit [Quit: Leaving]
zackr has quit [Remote host closed the connection]
khfeng has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
dviola has quit [Ping timeout: 480 seconds]
slattann has quit []
aissen_ has quit [Ping timeout: 480 seconds]
Akari has quit [Ping timeout: 480 seconds]
aissen_ has joined #dri-devel
dviola has joined #dri-devel
Leopold has joined #dri-devel
aravind has joined #dri-devel
khfeng has quit [Remote host closed the connection]
khfeng has joined #dri-devel
kts has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
khfeng_ has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
thaytan has quit [Remote host closed the connection]
slattann has joined #dri-devel
kts has quit [Quit: Leaving]
Duke`` has joined #dri-devel
thaytan has joined #dri-devel
bgs has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
foul_owl has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
bgs has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
foul_owl has joined #dri-devel
<lygstate>
../../src/egl/main/eglapi.c:2281:11: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]
<lygstate>
don't know how to fixes this
ahajda has joined #dri-devel
<Sachiel>
set a sensible value to it when it's declared
Duke`` has quit [Ping timeout: 480 seconds]
Akari has joined #dri-devel
danvet has joined #dri-devel
zaratustra has quit [Read error: Connection reset by peer]
mszyprow has joined #dri-devel
jlawryno has joined #dri-devel
slattann has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
frieder has joined #dri-devel
frieder has quit []
frieder has joined #dri-devel
yuq825 has joined #dri-devel
fab has quit [Quit: fab]
GeorgesStavracasfeaneron[m] has quit [Write error: connection closed]
yshui` has quit [Write error: connection closed]
moben[m] has quit [Write error: connection closed]
pushqrdx[m] has quit [Write error: connection closed]
nielsdg has quit [Write error: connection closed]
martijnbraam has quit [Write error: connection closed]
jenatali has quit [Write error: connection closed]
egalli has quit [Write error: connection closed]
Mis012[m] has quit [Write error: connection closed]
masush5[m] has quit [Write error: connection closed]
jasuarez has quit [Write error: connection closed]
zzoon[m] has quit [Write error: connection closed]
cwfitzgerald[m] has quit [Write error: connection closed]
Mershl[m] has quit [Write error: connection closed]
kunal_1072002[m] has quit [Write error: connection closed]
kunal10710[m] has quit [Write error: connection closed]
Eighth_Doctor has quit [Write error: connection closed]
Dylanger has quit [Write error: connection closed]
r[m] has quit [Write error: connection closed]
Tooniis[m] has quit [Write error: connection closed]
xerpi[m] has quit [Write error: connection closed]
Nirvin[m] has quit [Write error: connection closed]
tomba has quit [Write error: connection closed]
heftig has quit [Write error: connection closed]
Newbyte has quit [Write error: connection closed]
DemiMarieObenour[m] has quit [Write error: connection closed]
hasebastian[m] has quit [Write error: connection closed]
doras has quit [Write error: connection closed]
tleydxdy has quit [Write error: connection closed]
T_UNIX has quit [Write error: connection closed]
robertmader[m] has quit [Write error: connection closed]
halfline[m] has quit [Write error: connection closed]
Strit[m] has quit [Write error: connection closed]
Sumera[m] has quit [Write error: connection closed]
x512[m] has quit [Write error: connection closed]
Soroush has quit [Write error: connection closed]
sjfricke[m] has quit [Write error: connection closed]
gdevi has quit [Write error: connection closed]
reactormonk[m] has quit [Write error: connection closed]
onox[m] has quit [Write error: connection closed]
sigmoidfunc[m] has quit [Write error: connection closed]
AlexisHernndezGuzmn[m] has quit [Write error: connection closed]
mairacanal[m] has quit [Write error: connection closed]
YaLTeR[m] has quit [Write error: connection closed]
underpantsgnome[m] has quit [Write error: connection closed]
frytaped[m] has quit [Write error: connection closed]
bluepqnuin has quit [Write error: connection closed]
PiGLDN[m] has quit [Write error: connection closed]
DavidHeidelberg[m] has quit [Write error: connection closed]
LaughingMan[m] has quit [Write error: connection closed]
Guest4044 has quit [Write error: connection closed]
viciouss[m] has quit [Write error: connection closed]
MatrixTravelerbot[m]1 has quit [Write error: connection closed]
dcbaker has quit [Write error: connection closed]
undvasistas[m] has quit [Write error: connection closed]
znullptr[m] has quit [Write error: connection closed]
zamundaaa[m] has quit [Write error: connection closed]
nyorain[m] has quit [Write error: connection closed]
naheemsays[m] has quit [Write error: connection closed]
Andy[m]1 has quit [Write error: connection closed]
kunal_10185[m] has quit [Write error: connection closed]
Anson[m] has quit [Write error: connection closed]
robertfoss[m] has quit [Write error: connection closed]
Labnan[m] has quit [Write error: connection closed]
danylo has quit [Write error: connection closed]
mripard has quit [Write error: connection closed]
neobrain[m] has quit [Write error: connection closed]
Wallbraker[m] has quit [Write error: connection closed]
bylaws has quit [Write error: connection closed]
chema has quit [Write error: connection closed]
Ella[m] has quit [Write error: connection closed]
dafna33[m] has quit [Write error: connection closed]
michael5050[m] has quit [Write error: connection closed]
cleverca22[m] has quit [Write error: connection closed]
Vin[m] has quit [Write error: connection closed]
RAOF has quit [Write error: connection closed]
gallo[m] has quit [Write error: connection closed]
eyearesee has quit [Write error: connection closed]
aura[m] has quit [Write error: connection closed]
ralf1307[theythem][m] has quit [Write error: connection closed]
Jean[m]1 has quit [Write error: connection closed]
kallisti5[m] has quit [Write error: connection closed]
cmeissl[m] has quit [Write error: connection closed]
tintou has quit [Write error: connection closed]
Guest4054 has quit [Write error: connection closed]
knr has quit [Write error: connection closed]
JosExpsito[m] has quit [Write error: connection closed]
ella-0[m] has quit [Write error: connection closed]
pac85[m] has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
KunalAgarwal[m][m] has quit [Write error: connection closed]
jekstrand[m] has quit [Write error: connection closed]
Weiss-Fder[m] has quit [Write error: connection closed]
ramacassis[m] has quit [Write error: connection closed]
kusma has quit [Write error: connection closed]
hch12907 has quit [Write error: connection closed]
DrNick has quit [Write error: connection closed]
arisu has quit [Write error: connection closed]
srslypascal is now known as Guest4134
srslypascal has joined #dri-devel
Wallbraker[m] has joined #dri-devel
Guest4134 has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
tzimmermann has joined #dri-devel
<jadahl>
MST connected monitors actually lighting up when they get a mode set seems racy (on drm-next from a coupe of weeks ago). is that a known issue?
Leopold has quit []
<airlied>
Lyude: ^
fab has joined #dri-devel
mvlad has joined #dri-devel
rahul_janga has joined #dri-devel
rasterman has joined #dri-devel
tursulin has joined #dri-devel
ngcortes has quit [Quit: Leaving]
mbrost has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
<tzimmermann>
javierm, we could try to add conversion helpers proactively. but that might also backfire with having too many helpers that no one ever uses :/ maybe we can pick a few sensible choices?
<javierm>
tzimmermann: I actually think that the current approach of adding them as needed is better
<tzimmermann>
ok
<pq>
tzimmermann, why does simpledrm need to advertise support for 10 bpc even if the underlying FB is 8 bpc?
arisu has joined #dri-devel
Andy[m]1 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
Guest4139 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
Guest4154 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
Nirvin[m] 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
<tzimmermann>
pq. ease of implementation, i guess
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
<javierm>
yeah, the list is static
pmoreau is now known as Guest4160
<javierm>
I guess another option is to only advertise the current fb format and build the list dynamically
<pq>
tzimmermann, that sounds like something to fix. It's not nice to userspace to silently truncate color resolution.
<tzimmermann>
pq, there's exactly one format that the preconfigured scanout buffer supports. and we have no means of changing that
<tzimmermann>
so there will always be a filtering process, unless userspace picks the native format
<pq>
and if userspace knows what the real format is, the kernel does not need to do hard work converting pixels, but I understand that it's not possible to omit XRGB8888 in any case.
<tzimmermann>
and we already put the native format first to give userspace a hint on it
<javierm>
pq: problem is that some user-space only support XRB24 so we need some conversion for that case at least
<pq>
however, there is no reason to not omit 10-bpc formats if all you do with them is to truncate to 8-bpc.
<tzimmermann>
if we start filtering the format list, we'd need rules for this
<javierm>
IOW, at the very least we need to advertise the native format and XRGB24
<tzimmermann>
so that's just shifting the problem
<pq>
It's not shifting the problem. I had never even heard that the kernel format list might be ordered.
<javierm>
tzimmermann: do we put the native format first? I thought that just advertise the list of formats as defined and the first one in the list is the default?
<pq>
native format + XRGB8888 would be the best, yes.
<javierm>
tzimmermann: ah, I just read drm_fb_build_fourcc_list()
<pq>
since you cannot change the native format, do not advertise anything else except XRGB8888
<pq>
*else than the native format
<tzimmermann>
pq, xrgb8888 is the de-factor default for most of userspace. but that can change. it used to be rgb16 and sometime soon it could be rgb30. filtering that list is really just shifting the problem elsewhere
<pq>
tzimmermann, I disagree.
<javierm>
tzimmermann: I think that agree with pq here. The list of formats in the driver seems a little bit arbitrary
<pq>
tzimmermann, userspace no longer assumed that something else than XRGB8888 is always supported.
<javierm>
so native + XRGB8888 seems like a good heuristic to me
<javierm>
that is, we should only have DRM_FORMAT_XRGB8888 in the simpledrm format list and then drm_fb_build_fourcc_list() expose native + DRM_FORMAT_XRGB8888
<tzimmermann>
that is all temporary. with apply using rgb30, it's easy to see that it'll be that at some point
apinheiro has joined #dri-devel
<tzimmermann>
the current approach gives us a clear error message that is action-able. i strongly prefer that
<javierm>
pq: what about this, I add the drm_fb_xrgb2101010_to_xrgb8888() to fix this particular issue. That could even be backported to stable
<javierm>
pq: then we can discuss if you want changing the default behaviour
<pq>
Modern userspace will look for its preferred formats first, and use if found. If not found, it quits. Old userspace may use XRGB8888 blindly, which is why the kernel needs to emulate that. And since the kernel always offers XRGB8888, modern userspace knows to look for it and use it when nothing else works.
<pq>
tzimmermann, I do not believe the day will come when userspace assumes XRGB2101010 is always available.
<tzimmermann>
and you could go back 15 years and make that same argument about rgb16. it's not a valid long-term strategy. at some point, userspace will want to change
<pq>
tzimmermann, you can also be proactive about that: do not fake XRGB2101010 support if it's not useful, and userspace won't take it for granted.
<pq>
tzimmermann, I think you need to go much further than that, to the 90s.
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<pq>
tzimmermann, please, do not fake 10-bpc support. Nothing good will come out of that.
<tzimmermann>
in a few years, rgb30 will likely be standard. that doesn't depend on simpledrm
<pq>
the only thing it could achieve is that userspace starts assuming it earlier, when it's still a lie
<pq>
I beg you to not lie in the driver.
<pq>
you are not fixing any old userspace with that lie, and it's not necessary for fixing any kernel regression either
<pq>
XRGB8888 can be a lie too, but it's necessary for old userspace that knows nothing else. Please, do not turn XRGB2101010 into the same.
<tzimmermann>
how about we start by fixing the tone and not speak of *lying*
<pq>
I'm talking about the driver, not you.
<pq>
what word should I use instead?
<javierm>
pq: what about software emulated formats :)
<javierm>
instead of lies
<pq>
sure, s/lie/software emulated format/g
<pq>
do I need to repeat my statements with that?
<javierm>
pq: I don't think so and I do agree with you
<javierm>
that is, set on XRGB8888 as the assumed default for user-space that should know better and start advertising only native + XRGB8888
<pq>
Thank you. This also applies to all drivers, not only simpledrm.
<javierm>
pq: yes, agreed
<javierm>
pq: I think that's a separate discussion though and we still need to fix this particular bug
<javierm>
and IMO that's by addding a software emulation for rgb30-to-rgb24.
<pq>
that seems risky
<pq>
you may not be able to remove that later
<javierm>
pq: hmm, why so? We are advertising today anyways
<javierm>
so if we can't remove it, then it's too late
<pq>
but today it doesn't work, right? So no userspace can depend on it today.
kts has joined #dri-devel
<javierm>
pq: yes, but they can claim is a bug in the kernel. And I would agree with that
<javierm>
and also we need a fix that can be backported
<javierm>
a drm_fb_build_fourcc_list() rework doesn't seem something I would like to backport
<pq>
Removing an advertised format that never worked on a given system is not a regression. Removing a format that worked through emulation, someone might jump on that.
<pq>
ok
<javierm>
hmm, that's a good argument too...
<pq>
up to you of course
pcercuei has joined #dri-devel
<javierm>
pq: another option is to fix this in kwin and make it prefer the first format on the list, that's the native format
<jannau>
the bug in the kernel is that it announce the format when it doesn't support
<javierm>
jannau: exactly. So my opinion is that we need to fix that regardless
<pq>
javierm, I think that might be hard to sell. They just argue it's a kernel bug in the first place.
<javierm>
pq: but shouldn't they do that anyways? I mean, SW emulation could be costly in some platforms
<pq>
javierm, when was the format list made ordered? I don't remember hearing about that.
<pq>
also, how would userspace know if the kernel's recommendation should or should not override what userspace would prefer?
<jannau>
javierm: the fix for that bug is to not announce support for XRGB2101010 not trying to emulate it
<javierm>
jannau: Ok, so you then agree with pq that the drivers should only announce native + XRGB8888 and nothing else ?
<javierm>
and is OK to remove a format that was previously (wrongly) advertised ?
<pq>
then again, the preference orderof formats is kind of secondary, when the kernel is clearly saying a format works when it cannot.
<javierm>
pq: if removing a non-working format that was previously listed is acceptable for user-space, then yes we could just change that
<javierm>
unusre about the backporting situation since that would be a bigger patch
<pq>
javierm, yeah, by definition, if something never worked, it cannot be a regression.
<jannau>
yes, I agree. emulated format should only advertised when unavoidable
<javierm>
jannau: I see. I was thinking that could be threated as separate issues but I understand pq's and your point
<jannau>
writing SIMD optimised pixelformat conversions is much easier in userspace
<jannau>
not to mention that code already exists
<pq>
VKMS would be a totally different matter, because its whole purpose is to emulate everything.
<marcan>
oh, talk was happening here without me
<marcan>
I already have a patch for making simpledrmfb not advertise formats it can't support
<marcan>
it doesn't make any sense to advertise formats that aren't supported
<marcan>
and it's a pretty simple backport
<marcan>
if we want to add a conversion helper, we can do that later
<pq>
cool!
<marcan>
(but if we add a conversion helper, kwin will regress in performance with the current behavior, so that needs to be fixed anyway)
<javierm>
marcan: awesome
<pq>
a good point
<MrCooper>
FWIW, I'm with pq on this one
<javierm>
marcan: and yes, agreed that kwin should be fixed regardless
<marcan>
and yes, this isn't a regression of a prior feature, it's a new broken feature. so it's fair to remove it if it never worked.
<marcan>
(as long as we don't regress our machines, i.e. the ones which *do* support XRGB2101010 natively)
<javierm>
marcan: that's OK because it will be listed as a native format
<marcan>
sort of
<pq>
going on a tangent, how would kwin know when to use the first format in the kernel list vs. picking its own preference?
<marcan>
the A/X duality needs to be handled via dummy conversion helpers
<marcan>
so that is still required
<marcan>
otherwise it would be a regression
<marcan>
(but my patch takes care of that)
<marcan>
FWIW this was always broken for RGB565 and RGB888 too, so it's not new, it's just that kwin happens to like 10-bit formats over 8-bit and not those
<marcan>
the conversion matrix was never complete
<pq>
what's the A/X duality issue with kwin? why would the driver need to convert between A and X?
<marcan>
it doesn't, but there is only one "native" format
<marcan>
so if the native says X, A has to be advertised as a "conversion" even though it isn't
<pq>
why?
<marcan>
because otherwise it will not be advertised
<marcan>
(and that would be a regression, for one)
<pq>
because it easy to advertise with a no-op conversion, just for fun?
<marcan>
I mean, it already is
<marcan>
and we can't remove that now
kts has quit [Quit: Leaving]
<marcan>
plus it doesn't make sense not to do that
<marcan>
snice dumb FBs don't care about alpha
<pq>
well...
<marcan>
(generally)
<pq>
you can always accept A where hardware uses X and hardware would do nothing with A anyway.
<pq>
but that's the only case
<marcan>
that's arguably correct, but not the behavior today
<pq>
but you cannot accept X if hardware uses A
<marcan>
the behavior today is that X->A is accepted and treated as a no-op
<marcan>
so if anyone out there is running DTs that say A in simple-framebuffer, "fixing" this would regress them
<marcan>
I don't think it's worth it, given that likely 0 people are actually using A in a simple-framebuffer except by mistake
<pq>
X channel can contain garbage, and drivers need to be able to cope with that. I think IGT tests that nowadays.
<marcan>
yes, but there are likely 0 users claiming A where A is actually interpreted, here
<javierm>
pq: but if the driver is ignoring the alpha channel then that's not a problem right?
<pq>
marcan, right, but even if the DT says A, does that hardware do anything with A? If not, no harm.
<marcan>
right, and chances are it doesn't
<marcan>
I'm saying I'd bet on that over betting that nobody put A in the DT by mistake
<marcan>
since it's been allowed until now
<javierm>
marcan: and it worked so that would be indeed a regression if removed
<pq>
so, yes, I agree. If it used to work, it needs to continue to work.
<marcan>
qcom/sdm630-sony-xperia-nile.dtsi- format = "a8r8g8b8";
<marcan>
found one already
<marcan>
heck is x8 even a thing here?
<marcan>
tons of DTs saying A
<pq>
:-P
<marcan>
we actually use X in our DTs
<marcan>
but it seems ~everyone else got this wrong
<marcan>
so there you go
<marcan>
if you want to change this, have fun with regressing everyone else again :-)
<pq>
nope, it's "fine"
<javierm>
pq: on another tanget, I don't seem to find anywhere in the DRM/KMS docs about the the format list being ordered by preference
<pq>
just need to document why you can advertise X variant of a format if DT says A.
<marcan>
OK, let me see if I can repro the KDE problem, and prove the fix
<pq>
javierm, yeah, I did not know about such ordering either.
<javierm>
marcan: I think you should be able to reproduce it easily on a VM with virt-gpu since IIRC the framebuffer native format there is XRGB24
<marcan>
I can trivially switch our FBs to that (even if I don't change it for real), probably easier than spinning up a VM
<javierm>
marcan: ah, cool
<marcan>
colors will just look funny (when it works) :)
<javierm>
DT ftw!
<pq>
javierm, could you perhaps be confusing format ordering with Wayland? Wayland has some for dmabuf.
<tzimmermann>
IIRC rumor has it that some userspace simply picks the list's first entry. so the native format goes there
<javierm>
tzimmermann: I see. It actually makes a lot of sense I would say, it's just that isn't documented anywhere AFAICT
<javierm>
tzimmermann: so we just need to document I believe for user-space to know about this convention
<marcan>
(reworded a bit to pass checkpatch, will force-push later if everything else is OK)
<pq>
tzimmermann, you mean the one that starts with "I don't think this works, you need to allocate a custom format list with 3"?
<tzimmermann>
marcan, i'm still not happy, but I'm apparently the only one :/ i'd rather see a patch posted to dri-devel for review than here
<tzimmermann>
pq, yep. and IIRC I asked davnet about it here and the stupid-userspace-issue was the reason
<pq>
tzimmermann, I have never heard that userspace would pick the first entry of KMS format lists. I do know that apps do pick the first EGLConfig - does it come from that?
<tzimmermann>
no idea
<pq>
danvet, ^
<danvet>
pq, maybe only if you don't have eglconfig that gives you a sort order, but yeah the idea is that at least something it's sorted in preference order
<pq>
usually it is more difficult for usespace to use an arbitrary format than to use a format of its own choosing, so I'm kinda surprised.
<danvet>
but we're probably not very good at it
<danvet>
I was once looking into sorting it so that fbdev emulation would just pick the first one
<pq>
I can totally understand that fbcon could rely on this. But fbcon is in-kernel.
<marcan>
tzimmermann: I will post the patch for review as usual, of course
<marcan>
I'm just asking for comments here before I do that
<pq>
danvet, so the same question to you: how would userspace know when to pick the kernel recommended format vs. its own preferred format?
<danvet>
pq, yeah might be that no userspace relies on this now
<danvet>
pq, it doesn't
<danvet>
same way it can't tell where the tradeoff is between eglconfig for better rendering and kms for better display
<pq>
danvet, so what good could that sorting be for userspace?
<danvet>
pq, there still is generally a sorting that signifies "better for display"
<danvet>
which on sane hw at least aligns roughly with "better for rendering"
<pq>
I mean, it doesn't sound like userspace could ever use that sorted order.
<danvet>
so entirely unsorted seems silly
<danvet>
pq, so one case I'm thinking of is the entire bit depth limitations we have in some drivers
<danvet>
atm there's not really any way to convey that, and we could do that with sorting
<pq>
what's that limitation?
<danvet>
so compositors could try whatever they like first
<pq>
oh bandwidth?
<danvet>
and if that fails for atomic modeset, then try whatever the kms driver says is the "best for display"
<danvet>
bw, or memory, or whatever
<danvet>
if you go into details there's all kinds of stuff
<danvet>
like for 90/270 rotation you often need a specific display optimized tiling layout or it's not going to happen
<pq>
ok, so that actually is a way to know when to choose kernel recommendation vs. own preference.
<danvet>
so I do think there's some value in this, and compositor could switch to "I'll use display preference over egl preference" when there's an issue with atomic TEST_ONLY
<danvet>
but also I don't think kms drivers are consistent enough in this, and compositors arent fancy enough in their TEST_ONLY fallbacks yet
<danvet>
which is a bit chicken&egg
<pq>
right
<danvet>
so currently my take on this entire thing is that we should at least not intentionally make the sort order worse
<pq>
ok, cool
<danvet>
and I think it's ok to merge patches which improve it
<danvet>
like move native formats ahead of emulated ones and stuff like that
<pq>
is there a write-up about these ideas?
<danvet>
probably not
<marcan>
(if there are no comments, I'll send it to the list :p)
<pq>
yes, of course, I have nothing against ordering the format list per se. I was just surprised that changing the order could fix existing problems.
<pq>
or that userspace is somehow *expected* to follow the order against its own preference
<pq>
the atomic TEST_ONLY probing makes sense to me
<pq>
I mean using the kernel list order for picking fallbacks in order
<pq>
if the best format/modifier depends on rotation property, how does that work? You can't re-order the list, can you?
<pq>
marcan, reading through it now...
<daniels>
tzimmermann: I strongly agree with the others on not doing emulation btw, and I also don't see 2101010 becoming a universal baseline. 8888 was a huge improvement on 565/1555 in that it strictly expands all channels. 2101010 shrinks alpha, so anyone wanting more than binary alpha won't be using it, which means in many cases 2101010 is just an arbitrary expansion with no improvement in fidelity.
<pq>
XRGB16161616F could be the next universal standard after xRGB8888, I think
<marcan>
That technically regresses the supported formats
<marcan>
the driver right now supports RGB565/RGB888 for [XA]RGB8888 FBs
<marcan>
and [AX]RGB8888 cross-conversion which I suspect is actually critical, since as we saw a whole pile of DTs report a dummy alpha
<javierm>
marcan: hmm, we can keep those then
Akari has quit [Ping timeout: 480 seconds]
<marcan>
if I didn't screw up, my patch keeps everything that works right now, and no more
<marcan>
and in principle, if we don't want to add more conversions, it can stay like that forever
<javierm>
marcan: just remove the ones that we are missing the software emulated conversion
<marcan>
that's what I did
<marcan>
there are only conversions for some combinations, so a single table doesn't cut it
<danvet>
daniels, my take is that emulating xrgb8888 is ok because there's too much userspace out there that assumes it exists
<danvet>
everything else is very questionable
<danvet>
if we emulate more, then that looks like a mistake too me
<pq>
danvet, I agree.
<marcan>
I agree
<marcan>
I think it makes sense to keep what worked so far, drop what we pretended worked when it didn't, and never add any more emulations
<marcan>
(which is what that patch does)
<danvet>
ack
<pq>
yup
<danvet>
maybe we should also document that xrgb8888 might be emulated
<danvet>
and tell compositors they might instead use something that's higher up in the list
jlawryno has quit [Ping timeout: 480 seconds]
<pq>
+1
<danvet>
pq, I got really badly sidetracked finding the docs you asked for :-)
<danvet>
the toc is busted and you can't even navigate it anymore :-(
<pq>
danvet, lol, sorry :-D
<javierm>
marcan: I see. Yes, agreed
<danvet>
pq, anyway I think adding a paragraph to the IN_FORMATS property docs with what we discussed here would be good
<danvet>
if anyone volunteers :-)
<javierm>
marcan: I would then split in two patches, one for simpledrm as you do and another for drm_fb_build_fourcc_list() to drop the warning about no conversion helper
<javierm>
(since we don't want to add more)
<marcan>
it's not just a warning, it actually early-exits, so that would make the midpoint broken
<pq>
marcan, please have: Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
<javierm>
marcan: yeah, I meant that bit to split in a separate patch
<marcan>
right, I'm saying if I do that then the inter-patch state is more broken in some way, regardless of patch order, which AIUI is a bad idea
<marcan>
(either it breaks things that work or advertises more broken formats in cases where they aren't right now)
<danvet>
javierm, scrap it, this doesn't change the toc I want to change :-/
jlawryno has quit [Remote host closed the connection]
jlawryno has joined #dri-devel
<javierm>
:(
<danvet>
somehow building locally I get a tad more toc depth in the sidebar than what the autobuilder does
* danvet
confused
<marcan>
oof, I just tried KDE on wayland as a test and it sets the display scale on startup, but that races with plasmashell (and possibly other apps) starting, which means the plasma panels are randomly blurry or not on every login...
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
<marcan>
I really need to start chasing down these issues, I was hoping to switch us to wayland once lina/alyssa's GPU driver is in shape, but... stuff like this needs to work
<marcan>
anyway, seems I didn't break us, so I'll send the patch
<marcan>
done
<tzimmermann>
marcan, why do you need to modify simpledrm at all?
<marcan>
because right now it's broken and it advertises formats that it can't support
<gawin>
eric_engestrom: thx
<marcan>
(if someone wants to move *all* the conversion format selection logic out of simpledrm and into a helper, that would certainly also work, but right now the table is in simpledrm and that table needs changing)
<eric_engestrom>
gawin: thx for the reminder ^^
<tzimmermann>
marcan, but in your patch, there's a large switch statement. sorry, i didn't really follow the conversation, but why not build naive+xrgb8888?
<marcan>
because that regresses things which are supported today
<marcan>
the goal of the patch is, as I said above, to keep everything that works today working, and stop advertising formats which are broken
<marcan>
no more, no less
<marcan>
the tables have every entry that works today, so the driver will now advertise only everything that worked so far (which means we don't regress), and stop advertising things which were broken (which fixes the problem)
<marcan>
the switch statement is required because conversion is a sparse 2D matrix, it cannot be represented by a single list
<javierm>
tzimmermann: that's what I suggested too (https://paste.centos.org/view/raw/3390543a). I do wonder in practice if other than native and xrgb8888 is really used...
<marcan>
(and the matrix of supported conversion helpers today doesn't have any particularly nice description)
<tzimmermann>
marcan, the thing is that it's not only about simpledrm. i recently added ofrm, which is similar, but for another platform. and ideally, we'd want to call drm_fb_build_fourcc_list() for all drivers that do some kind of internal format conversion
<marcan>
sure, I expect this to be refactored once drivers start using the helper, and possibly move the tables into the helper or figure out how to make it more generic
<tzimmermann>
it means that drm_fb_build_fourcc_list() should contain that logic
<marcan>
but right now there is a longstanding bug and a newer regression and this is a fix (with stable backports) patch to fix that
<javierm>
tzimmermann: exactly my thoughts, specially if the agreegment is that will always be native + xrgb8888
<marcan>
bikeshedding over how the code should look in the future when drivers start using it can happen when those drivers actually start using it :)
<marcan>
but that kind of work is specifically *not* in scope for stable backports, and this is Cc: stable
<pq>
marcan, no, I... wait, what am I a maintainer of? :-O
<marcan>
:D
<karolherbst>
congrats to your surprise maintainership
<pq>
marcan, anyway, I like emailing through gmail, but I need to use collabora.com for the tags.
<marcan>
fair :)
<marcan>
javierm, tzimmermann: keep in mind that the rules for stable are even *stricter* than regular "don't break userspace" rules. I'm going for the minimal *correct* patch here that doesn't regress anything and fixes the problems.
<marcan>
I'm not saying this is the One True Way :)
zaratustra has joined #dri-devel
<marcan>
but right now the kernel is broken and I'd rather get this fixed and backported
<tzimmermann>
marcan, it's not just bikeshedding. if we end up with simpledrm and ofdrm having different semantics here, we might create the next problem
<marcan>
as I said, right *now* this patch strictly *fixes* things that are broken, and strictly *doesn't remove* any functionality
<marcan>
therefore it is strictly an improvement over the status quo, and should be uncontroversial
<javierm>
marcan: honestly as I mentioned, I think the correct fix for stable is to add drm_fb_xrgb2101010_to_xrgb8888()
<tzimmermann>
marcan, one sec
<javierm>
since the kernel is advertising that format
<marcan>
javierm: I disagree, that will just have KDE doing double conversions which is a performance regression
<marcan>
it should just not advertise that which it doesn't do
<javierm>
marcan: yes, but then is a KDE regression not the kernel. Is KDE that chose to use a software emulated (although broken) format
<javierm>
marcan: there are other formats that are advertised and emulated today, KDE should pick the first one that's the native one
<marcan>
if you pin KDE to the current version and look at kernel, KDE works -> KDE doesn't work -> KDE works slower
<marcan>
that's not great
<marcan>
yes, I agree
<marcan>
but that doesn't mean the kernel has to start providing new conversions
<javierm>
marcan: agree. We can close the door after drm_fb_xrgb2101010_to_xrgb8888() but IMO that should be implemented now
<marcan>
plus, there are other missing conversions, which we'd have to also add (all the combinations of rgb565 and rgb888)
<marcan>
which is silly
<javierm>
marcan: yeah, probably just adding all advertised formats -> XRG8888 would be enough
<tzimmermann>
marcan, javierm, i've seen the patch on dri-devel. i'd rather like to move the discussion there
<marcan>
if your argument is "the kernel should provide conversions for everything advertised to this date" then we also need rgb565->rgb888, rgb888->rgb565, rgb565->xrgb2101010, rgb888->xrgb2101010, xrgb2101010->rgb565, xrgb2101010->rgb888
<marcan>
want to write all those helpers? :)
<marcan>
because just one doesn't solve the problem
<danvet>
jani, ^^ I have no idea why we didn't set this years ago, it makes it so much nicer
<danvet>
you can now navigate i915 to their full depth in the sidebar
<danvet>
epic
* danvet
off to prep lunch
<danvet>
a bit late, I'm really hungry
<daniels>
javierm: 'emulated format' is not exactly part of uAPI though ... I'd personally never heard of 'you should pick the first format' before now, especially as that would suggest on a lot of Intel hardware that C8 is the native format and everything else is 'worse' ...
<javierm>
daniels: Ok
<tzimmermann>
marcan, we're most of all fixing drm-tip and not stable. if they want the fix, good. but drm trees come first IMHO
<javierm>
daniels: yes, a sub-topic about that convention not being documented was lost in the simpledrm format disucssion
<jani>
danvet: nice
<danvet>
daniels, reality is a disappointment
<danvet>
jani, not sure this was only recently added or whether I was just dense or something
<danvet>
but yeah, so much easier to navigate the docs with this
<jani>
or we just didn't look too hard
<danvet>
yeah maybe
<danvet>
I always tried to fumble around with :toctree: options, and those do nothing for the sidebar
<javierm>
marcan: you can also send a different patch for stable, not necessarily the same that landed upstream but a variation
<javierm>
so agree with tzimmermann to focus on drm-tip first
<javierm>
daniels: and IMO we should just drop all the emulated formats and just keep XRGB8888 besides the native one. Question is how user-space would know what will give it the best performance and avoid emulation?
lemonzest has joined #dri-devel
<pq>
javierm, as danvet suggested, XRGB8888 can be documented as "potentially emulated". Anything else ideally is not emulated. That's how.
<pq>
if the hardware for is XRGB8888, then you don't expose any other format, and userspace cannot avoid doing the right thing.
rahul_janga has joined #dri-devel
<javierm>
pq: right, if that's documented then great
<daniels>
the IN_FORMATS blob is also extensible; you could add a per-format is_emulated array to the end of it
<pq>
javierm, I mean, there is no way for userspace to know today, because userspace simply doesn't look at anything. Whatever it is, is going to be future.
<daniels>
(or realistically, per-format flags)
<javierm>
pq: yeah, it was a rhetorical question as an argument that we should just drop all the emulated formats if we don't want to regress performance
<marcan>
replied to the patch with some of the arguments mentioned here (and my replies)
<marcan>
tzimmermann: I think stable generally wants regressions fixed... it's kind of the point of stable, and probably important here where real distros broke with real DEs.
<pq>
if you can get away with that, all the better, but if someone complains about a regression, then you have to do what marcan coded.
<javierm>
pq: my intuition is that other than native and XRGB8888, nobody would really care
<marcan>
https://paste.centos.org/view/raw/3390543a has one problem, it doesn't advertise free ARGB2101010 -> XRGB2101010 conversion, which is probably a good idea. I don't know if any of our userspace depends on that right now, but it might.
<javierm>
pq: even for the bug that brought this issue up, KDE would happily work if the XRG2101010 format goes away
<pq>
javierm, I hope you're right :-)
<marcan>
also, that still needs the helper patch I have, it won't work without that.
<pq>
javierm, btw. did you forget to drop RGB888 in that snippet?
<marcan>
that too
<javierm>
pq, marcan: I did, yes
<javierm>
-ETOOMANY8's :P
<javierm>
marcan: thing is that if we keep ARGB2101010 -> XRGB2101010, then we open the gate of SW emulated formats
<javierm>
IMO it should be all or nothing
<marcan>
ARGB2101010 -> XRGB2101010 is free, there is no emulation involved
<marcan>
by definition all drivers that take XRGB2101010 can take ARGB2101010
<marcan>
for simpledrm it's the same codepath, a memcpy in both cases
genpaku has quit [Remote host closed the connection]
<danvet>
uh A vs X has a pretty clear meaning
<pq>
...until we start having transparent displays
<danvet>
with z index and background color
<danvet>
and yeah that too
genpaku has joined #dri-devel
<javierm>
marcan: is emulation if you are dropping the alpha channel
<marcan>
I mean there is no actual conversion
aravind has joined #dri-devel
<danvet>
so I guess you could add A in all the cases where it doesn't matter, but compositors need to think about this case anyway explicitly so I don't see any win here
<marcan>
pq: A->X means taking an image with A and ignoring it, not taking an image with garbage and interpreting it as A
<javierm>
marcan: yes, but is not what the native framebuffer format as set up by the firmware
<marcan>
if you think that's better not to advertise, I'm okay with that *as long as* it doesn't regress real userspace for us today
<pq>
marcan, until you are driving a transparent display where A is meaningful, userspace intentionally uses A, and your driver just drops it on the floor.
<marcan>
I don't know what compositors/X is actually picking of those two options, and whether only having X would regress something, off the top of my head
<marcan>
pq: if userspace uses A it would hopefully actually pick an A format?
<marcan>
if userspace is picking an X format over A that's a userspace bug
<marcan>
the driver could just support X anyway
<marcan>
oh wait, sorry, okay
<pq>
marcan, userspace does, but then your driver silently converts it to X
<javierm>
marcan: yes, what I propose is the following. Drop everything and only keep native + XRGB8888. And then add emulation for formats if people complain and report a regression
<marcan>
I confused myself there
<pq>
hehe
<javierm>
marcan: but then we have a clear policy, we only add what's needed to fix regressions and nothing more
jlawryno has quit [Ping timeout: 480 seconds]
<javierm>
if others agree I can post that patch with a proper commit message
<marcan>
javierm: that's fair, but I still think the right thing is to merge my patch in first and then we can always revert to a simpler version for -tip, since this patch is guaranteed not to regress anyone
<marcan>
(I didn't say this patch had to go in -tip, but it needs to go into -fixes or whatever branch DRM uses for -rc stuff)
<pq>
javierm, marcan, in the of ARGB2101010, I think the regression question is the most important one: Did the driver expose and work with that before? If yes, I think that's a good justification to keep emulating it, unless you want to test if anyone will complain. Even better if you test and no-one complains.
<pq>
*in the case of
<marcan>
yes, the driver has exposed X/ARGB2101010 on hardware with X/A and both options always worked
<marcan>
(ever since my patch to introduce it)
<marcan>
as I said, my patch, unless I screwed up, *strictly* removes broken things and doesn't add any new things and keeps everything that was working working
<pq>
has that patch been in releases yet?
<marcan>
yes
<pq>
ok
<javierm>
marcan: I'm OK with your patch landing first and then figuring out the way forward
<pq>
so it's a case of emulating ARGB2101010 *iff* the hardware format is XRGB2101010.
<pq>
and maybe vice versa
<marcan>
yes (and vice versa, which could be arguably wrong but is actually required for [ax]rgb8888 because people can't write device trees, apparently... that just followed the 8888 logic)
<marcan>
we don't depend on vice versa for our platforms, our DTs have always said X
<marcan>
so if we're the only user I don't care about vice versa
<javierm>
pq: I would be surprised if a system framebuffer would support ARGB2101010
<marcan>
javierm: hopefully there are no users of that, but there *are* a pile of system FBs falsely claiming ARGB8888
<pq>
javierm, me too, but OTOH it's trivial to "support".
<javierm>
pq: it's trivial but then would be an exception to keep in the simpledrm driver...
<pq>
yes
<javierm>
and one could argue then why not support all the others
<pq>
so the main question is, would anyone notice if it's gone?
<pq>
no
<marcan>
let me just drop A and see if anything breaks for us
<javierm>
marcan: please, that would be helpful
<marcan>
if so I'm fine with removing it (but still think that should happen in a separate patch)
<javierm>
marcan: yes, I agree with yours landing first, being picked by stable and then deciding what to do moving forward
<pq>
maybe someone's GPU driver does not like rendering into XRGB or they just pick ARGB rendering by accident. That's very easy with EGL. Then they forget to bother to say it's XRGB to KMS and just say what it is really is: ARGB. That way someone might be depending on KMS ARGB support.
<marcan>
yeah, something like that...
<pq>
so it's not /that/ far-fetched to think that some userspace could depend on ARGB KMS by accident
Lucretia has quit []
Lucretia has joined #dri-devel
<marcan>
I don't see anything broken, xorg/kde-wayland/gnome-wayland/weston all work
<pq>
cool :-)
<marcan>
I can't tell if there are performance regressions though (e.g. something formerly using ARGB2101010 now using [AX]RGB8888 via kernel conversion, because it doesn't know how to do XRGB2101010)
<marcan>
but I can live with that
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
<danvet>
daniels, yeah maybe we need perf/functionality hint flags more than ordering for kms formats
<marcan>
(*I* can live with that, probably a lot more than people running kwin on other simpledrm platforms... which probably have less than 10% of the CPU oomph of these things :p)
<marcan>
(hence why I'm a lot more opposed to adding the 2101010 -> 8888 helper :p)
<danvet>
stuff like marking some formats as expensive to scan out
<danvet>
or preferred/required for rotation
<danvet>
I think those are the most common things I've seen in hw
<danvet>
maybe two flags, one for stuff that's substantially more expensive to scan out than linear (like Y tiling on i915 due to fifo requirements)
<danvet>
and stuff that's substantially better to scan out than linear (like afbc)
<danvet>
pq, ^^ does something like this sound more useful than just dumb ordering?
<marcan>
pq: how about I push the A drop to our tree in our next public build, and see if anyone complains?
<marcan>
I'm okay with breaking people and more okay if I get to fix it with my own builds instead of having to undo upstream changes and fight them :)
<pq>
marcan, sounds awesome :-)
<pq>
danvet, yes. And maybe also one flag per rotation orientation to signal which ones work vs. not.
<danvet>
pq, hm yeah, we could do a signed priority (with 0 = as expensive as linear)
<danvet>
and a mask for rotations or something
<danvet>
if we add flags
<pq>
danvet, if drivers can assign priorities meaningfully, then ok.
<pq>
that better/worse than linear sounded pretty nice to me
<danvet>
I'm thinking of fixed compression ratio formats with 2x or 4x compressin
<danvet>
i.e. lossy ones
<danvet>
but then more compression is worse quality
<marcan>
I wonder if anything depends on the 565->8888 or 888->8888 conversions... ancient userspace/examples?
<danvet>
I'm honestly not sure why these even exist
<marcan>
if those can be safely dropped then you could achieve 8888 being the only universal format thing (well, A/X so 2 variants)
<marcan>
danvet: maybe someone just added them for orthogonality?
<danvet>
the other way round makes sense to support xrgb8888 only userspace
<marcan>
yeah
<danvet>
marcan, yeah maybe, git log not shedding any clue?
aravind has quit [Ping timeout: 480 seconds]
<danvet>
oh vkms I think uses them internally or something, not sure
<danvet>
so that it supports more formats
<danvet>
but yeah anyone should not have any excuse
<pq>
VKMS is totally different here, the whole purpose of VKMS is to emulate all the stuff
<danvet>
yeah
<danvet>
so yeah might just be a case of someone asking "why not" instead of "why"
<marcan>
e08a99d005588
<marcan>
hi tzimmermann :)
<tzimmermann>
marcan, hi?
<marcan>
(that's your commit)
<marcan>
apparently this happens if you force the console format to those, which you could because of the spurious supported list
<marcan>
and some xorg settings?
<javierm>
yes, but we can make the driver to just error in that case
<javierm>
just like it would in a real driver if you try to use an unsupported format
<tzimmermann>
sorry, i'm not following the discussion closely
<marcan>
well, you can just have it not report it as supported and then if xorg decides not to start when it wants 16bit and KMS doesn't give it to it, sure
<javierm>
marcan: exactly
<javierm>
so I think only XRGB8888 and not ARGB8888 should be advertised
<javierm>
+ native obviously
<javierm>
if someone uses video=1024x768-16, well... they shouldn't
<marcan>
*shrug* from me, if nobody complains, not my subsystem :)
<javierm>
marcan: I mean, I think that either it should support any format or none. But otherwise seems arbitrary
<tzimmermann>
wrt to e08a99d005588 we (suse) had users reporting stuff not working when they had video= set
rahul_janga has quit [Ping timeout: 480 seconds]
<javierm>
that is, we either make the generic fb drivers to only support native + XRG88888 or add emulated formats as needed
<marcan>
the question is would it work if the driver stopped advertising that broken mode?
<marcan>
obviously it would badly break if it does, since it just hangs the console
<marcan>
but will video=stupid mode fall back to a working mode if not supported?
<javierm>
marcan: what would happen if you use video=foobar while foobar is not supported on a native driver that does not advertise emulated formats ?
<marcan>
same question
<pq>
marcan, maybe drm_fb_build_fourcc_list() already makes sure to not add the same format twice?
<daniels>
danvet: ooh yeah, I like that. CPU-expensive vs. HW-expensive.
<marcan>
pq: it does
<daniels>
danvet: fwiw for fixed-rate compression modifiers, both GL/VK make users very explicitly opt in to using them, so there's no danger of a naïve user accidentally walking into lossy compression
<marcan>
that reminds me that we still need to figure out what to do for notchful modes in KMS
<tzimmermann>
javierm, marcan , IIRC the original fbdev console of simplefb just works becaused it ignored video= . drm emulation is more picky. i had to fix videomode selection to make it pick a valid resolution if video= is nonsense
<marcan>
we need some way to report notch metadata, *and* make them opt-in only for compositors that know how to deal with it
<tzimmermann>
and that's why I added those format conversions as well IIRC
<marcan>
there's a discussion on the wayland tracker about this, but I don't recall anything on the KMS side?
<tzimmermann>
users use video= to configure their native driver's console
<daniels>
marcan: KMS already has client caps (i.e. client must positively declare support) for stereo etc modes, which are then filtered out of the list if userspace isn't aware of them
rahul_janga has joined #dri-devel
<marcan>
ah, yeah, then we need a notch cap, and some kind of metadata standard
<tzimmermann>
then they complain if the generic driver remains dark
<marcan>
tzimmermann: the driver would remain dark if it was picking an unsupported format, since then it would *think* it works but not
<marcan>
the question is, what happens if the format is correctly reported as unsupported
<marcan>
does it know to fallback? or does it punt elsewhere in the code anyway?
<daniels>
marcan: so you'd probably want a DRM_MODE_FLAG_NOTCHY, plus a blob on the CRTC describing the notch bounding box for each mode, i.e. 'for 1080p the notch is (700,0) -> (900,100), for 4K the notch is (1400,0) -> (1800,200)'
<marcan>
yeah, something like that
<javierm>
tzimmermann: that's for vesafb right? or did efifb also supported that?
<daniels>
s/CRTC/connector/
<marcan>
there's quite some bikeshedding going on in that bug for what level of detail to report the notch as
<javierm>
I guess that for vesafb, it just blindly tries to set the VESA mode
<marcan>
because it's also rounded corners
<tzimmermann>
marcan, from the top of my head: by default fbdev emulation tries 32 bpp. you can force it to something else. if that 'something' isn't advertised, the console remains dark
<marcan>
my proposal was a list of rects, with a bitmask of which corners are rounded and a positive/negative flag; that can accurately describe the Mac notch/roundiness, as well as hole punches, etc. without going full let's have a list of vector splines
<tzimmermann>
javierm, both efifb and vesafb IIRC
<marcan>
and userspace that wants to interpred it more simply can just ignore the round flags and treat them as square holes
<marcan>
*interpret
<javierm>
tzimmermann: so if we want to support arbitrary video=$mode, then our only option is to keep adding emulated format conversion as needed
<marcan>
(but e.g. a WM might want to optimize for rounded corners by having icons intrude into them, where safe)
<tzimmermann>
javierm, alternatively, someone could dive into the fbdev emulation and fix format selection. if the selected format isn't supported, fbdev emu should try to pick one instead
<javierm>
tzimmermann: because the problem I guess is that simpledrm fails to probe and then fbcon doesn't have any fbdev to bind and that leads to the black screen
<javierm>
tzimmermann: right, just ignore the video=$mode if is not supported and use a default
<tzimmermann>
javierm, not really
<tzimmermann>
video= is an fbdev option
<tzimmermann>
it controls fbdev mode selection
<tzimmermann>
simepldrm probes and initialized the fbdev emu, which then fails
<javierm>
tzimmermann: right
<javierm>
so this is something to be fixed in the drm fbdev emulation layer? or fbcon?
<tzimmermann>
drm fbdev emulation
<tzimmermann>
i already fixed mode selection at some point. even if you enter a non-sense video relsolution at video=, fbdev will use some other mode
<tzimmermann>
that needs to be done for color formats as well, AFAICT
<javierm>
marcan, tzimmermann: so this is my proposal. Lets just add a drm_fb_xrgb2101010_to_xrgb8888() to fix the reported bug. Even when it will cause a perf penalty
<javierm>
then we can figure out what to do next
<javierm>
this seems to be a rabbit hole
<tzimmermann>
javierm, you remember that we have add explicit bpp values to some of the drm_fbdev_generic_setup(). it's because the format selection is somewhat buggy. this would be an opportunity to fix that as well
<tzimmermann>
but i cannot really say what needs to be done without close investigation
<javierm>
tzimmermann: agreed, first we need to a) agree on the move forward and b) fix which will require changes in drm fbdev emulation, the simpledrm/ofdrm drivers, how the list of fourcc is built, etc
<javierm>
so I think the least resistance path for now is to add yet another format conversion and then figure out the rest
<tzimmermann>
you don't have to convince me :)
<javierm>
or conversely apply marcan patch but my worry is that it's moving things forward but unclear if in the direction that we want
itoral has quit []
<tzimmermann>
i raised my concerns on dri-devel
jkrzyszt has quit [Remote host closed the connection]
<jannau>
daniels: fortunately the firmware just reports modes with display's native resolution on this sort of notchy devices
<daniels>
marcan: yeah, as long as the basic unit of expression is a bounding box, having addons like radius for each corner is fine I'd say
<daniels>
I don't expect very many users at all to try to take advantage of a few dozen pixels in a corner though
<jannau>
the radius on the top left corner is large enough to be annoying if things are rendered behind it, avoidance is imo more than nice to have
idr has joined #dri-devel
<tzimmermann>
javierm, btw. do you still have my fbdev cleanup on your list?
<javierm>
tzimmermann: I do, yes. I'll go through that today. Latest is v2 right ?
<tzimmermann>
yes.
<javierm>
Ok
<tzimmermann>
thanks a lot
<javierm>
yw
<tzimmermann>
it's not a popular topic, so reviewers are in short supply :)
<javierm>
:)
<pq>
javierm, what's unclear in the direction we want?
<pq>
javierm, if you add drm_fb_xrgb2101010_to_xrgb8888 in stable, you may be forced to add and maintain it in main as well, because people upgrade kernels from stable to stable.
<javierm>
pq: yes I know, but we have other emulated formats anyways. Adding one more wouldn't make things worse
<pq>
er, yes it does?
<javierm>
pq: how so? If we agreed that we could drop the others, then we could drop that one too
<pq>
but if the verdict is that you cannot drop what already worked, then you cannot drop this either
<pq>
or maybe you want to see if anyone complains
<javierm>
pq: correct. And we will need to keep adding others if there are more bug reports
<pq>
regression complaints are not all-or-nothing either, they will be per-format
<pq>
there cannot be bug reports for formats that never worked to begin with
gawin has quit [Quit: Konversation terminated!]
<pq>
yes, you will have to maintain a totally arbitrary set of emulated formats if someone complains, and that's the cost of implementing those in the first place. But they are not an excuse to add even more emulated formats, are they?
<pq>
why would you deliberately make more work for yourself?
<javierm>
pq: but were do you draw the line? For example, simpledrm reports DRM_FORMAT_RGB565
<javierm>
and there are format converstion for DRM_FORMAT_RGB565 -> DRM_FORMAT_XRGB8888
<pq>
the line is format by format
<pq>
having one format implies nothing about any other format
<javierm>
but one can claim that DRM_FORMAT_RGB565 works on some platforms but doesn't in others
<javierm>
pq: because following your rationale, DRM_FORMAT_XRGB2101010 -> DRM_FORMAT_XRGB8888 never really worked so there's no bug to report
<pq>
no, platforms do not need to have equal format support in general.
<javierm>
or would we need to implement DRM_FORMAT_RGB565 -> to everything just because that format is reported?
<pq>
um... yes? I think I lost you.
<javierm>
so I think is either only report native + DRM_FORMAT_XRGB8888 (and add converstions for that to native) or implement everything
<pq>
no, it's not an either-or
<pq>
it's format by format
<javierm>
pq: Ok, but if someone reports DRM_FORMAT_RGB565 -> DRM_FORMAT_XRGB2101010 not working for example, what we should do?
<pq>
we ask if it ever worked before on that specific platform
<pq>
if it did, it's a regression and the support must be reinstated
<javierm>
pq: Ok, and if it didn't? We sill still report because that's one of the formats reported by simpledrm
<javierm>
s/report/advertised
<pq>
if it did not, then we have a bug that we can fix by simply stopping to advertise RGB565
<javierm>
pq: Ok, but we currently don't have that logic. We first advertise and then try to convert
<javierm>
and fail if there's no format conversion helper
<marcan>
that's literally what my patch does
<pq>
right
<marcan>
adds that logic (to simpledrmfb)
<pq>
you need that logic
<javierm>
marcan: yes, I know. But at least for me is not clear we want to add that if we are going to drop anyways and only advertise native + XRGB8888
<marcan>
and tzimmermann is right that ideally we need that logic in the helper, and I agree that that refactor should happen - for 6.2
<marcan>
but for 6.1 and stables, my patch fixes things
<marcan>
and does not cause merge conflicts with ofdrm, only a minor regression (but that driver is not in any release yet) and it can be fixed without introducing merge conflicts
<marcan>
so I think we should fix ofdrm to work with the state this patch leaves things in (and also fix it advertising nonsense like simpledrm did)
<pq>
javierm, you don't know *yet* if you can drop. And stable kernels might not want to drop even if you can in main, just in case.
<marcan>
and then once that is merged after 6.1 lands, refactor things
<javierm>
pq: agreed. Hence my argument that adding the format conversion is simpler and less risky for stable
<marcan>
(or maybe drm-tip can merge whatever early and we can refactor early, so long as the git trees are consistent)
<pq>
javierm, I don't understand how you can say so.
<marcan>
(not sure how these trees are usually managed)
<marcan>
javierm: I still don't get how making things worse is the right thing to do, it doesn't make any sense
<javierm>
pq: why not? It's really trivial to add that format conversion, it's true that this will mean yet another emulated format to support in the future, but we advertise that...
<marcan>
if we add that to stable kernels it *becomes part of the ABI* whether we want it or not
<marcan>
it makes even less sense to have something added to stable kernels then removed again in mainline
<pq>
javierm, I don't think you should add new features in stable, right? xrgb2101010 has never worked before on that platform that would need the conversion, so it's a new feature if you make it work.
<marcan>
yeah
<marcan>
this makes zero sense
<marcan>
stable is for fixing regressions, and the regression here is that we started advertising a format that doesn't work
<tzimmermann>
i still think that the conversion helper is the go-to solution here and the best solution for stable. it's the solution *within* the current design. anything else would be more fundamentally
<marcan>
so we remove it
<marcan>
as my patch does
<marcan>
tzimmermann: I strongly disagree
<marcan>
adding features to stable is forbidden
<marcan>
(modulo device quirks)
<tzimmermann>
the next best thing is the helper-based solution
<marcan>
stable is for fixing *regressions*
<pq>
javierm, and if you make it work in stable by adding the conversion, that could be just yet another conversion you cannot take out later. So you just added a conversion for no reason, and might get stuck with like with all the already working conversions.
<javierm>
marcan, pq: what tzimmermann said. I don't feel confortable doing what's basically a refactoring as a stable fix
<marcan>
the *regression* here is a broken format was advertised
<tzimmermann>
throwing things into simpledrm is the least-best idea.
<marcan>
the *fix* is equivalent to reverting my original patch (except without removing functionality and creating other regressions): removing the spurious advertisement
<marcan>
tzimmermann: again, this is a *fix*
<marcan>
this isn't about development
<tzimmermann>
we want a solution, but not any solution
<marcan>
this is about fixing a *regressions*
<marcan>
we can refactor later
<tzimmermann>
and affected distros can still apply you current patch
<marcan>
... that is what stable is for
<tzimmermann>
no it's not
<marcan>
yes it is?
<marcan>
distros pick up stable
<javierm>
pq: one can argue that the original sin was advertising that format not supported, the correct fix is subjective
<javierm>
for you is to not advertise, for me is to support it
<marcan>
if we keep a regression fix out of stable, and distros have to manually patch it, then we have failed, and it's also work amplification
<tzimmermann>
at least we don't blindly take things from stable, although it can be convinient
<javierm>
for stable I mean. Then we can decide if the SW emulationg could be deprecated
<pq>
refactoring? I did not see any refactoring in marcan's patch.
<marcan>
javierm: it is not subjective
<marcan>
again: *regression*
<marcan>
by definition the fix for a regression is to go back to the behavior *prior* to things breaking, without regressing anything else
<marcan>
and that means unadvertising the format
<marcan>
it is *not* to make work something that never did
<tzimmermann>
just this week, someone backported a patch of mine to stable and then i had to fix things to get it working. although i never asked for the patch to be in stable
<javierm>
marcan: but you can consider that the regresion is to not be able to choose an advertised format
<javierm>
marcan: because before you could choose *any* format and it would work
<marcan>
no you couldn't
<marcan>
there were other broken formats
<marcan>
so there is no change there, we just added one more broken format
<javierm>
marcan: yes, but that was already a regression that just nobody noticed
<marcan>
actually no, they were broken from the get go in this driver
<marcan>
:)
<marcan>
so they aren't regressions, they're just bugs
<marcan>
the recent addition was an actual regression
<javierm>
marcan: well, then it was a regression when using simpledrm instead of efifb
<zamundaaa[m]>
What would be the actual purpose of advertising inefficient formats that never worked before? It certainly doesn't prevent any regressions, it just causes more
<marcan>
that's arguable, yes
<javierm>
marcan: that's why I said that is subjective and not that clear to me what's the actual regression and fix
<marcan>
even if you consider it subjective, it seems pretty clear to me that the least dangerous fix is to remove the format
<marcan>
since *nobody* expects it to work, by definition, since it never did
<pq>
javierm, no KMS driver should ever emulate any pixel formats, VKMS and XRGB8888 notwithstanding, and unless removing a format would be seen as a kernel regression.
<marcan>
and doing so is guaranteed to fix the regression for users, without adding future burdens
<marcan>
making the format work suddenly means people can *start* depending on it
<marcan>
and that is committing to something new
apinheiro has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
Userspace that handles anything more than xrgb8888 shouldn't rely on any specific formats being available anyways
<zamundaaa[m]>
I'm pretty sure there's no such userspace program doing that
<marcan>
plus it would still be a performance regression
<marcan>
which is still bad
<marcan>
(just less bad)
<javierm>
pq: I agree with you that drivers shouldn't advertise anything more than xrgb8888 and native, but I disagree on the proper way to fix this issue
<marcan>
again, if your plan is to support everything ever advertised, you'd have to add not just one helper, but a whole pile
<marcan>
if that is not your plan, then what's the argument for doing it just this once?
<javierm>
the original sin was to advertise anything else than native + xrgb8888
<javierm>
marcan: my plan is to add on a per bug report basis
<marcan>
"per bug report basis"?
<marcan>
the bug is fixed whether we add the format or remove it
<marcan>
and for the other formats, we need to either add the helpers or remove the formats
<javierm>
marcan: yes, I wouldn't mind if we just don't advertise it at all
<marcan>
why does it matter whether someone reported a bug or not?
<zamundaaa[m]>
javierm: please don't ever advertise formats that don't work. Either advertise a format and support it, or don't advertise it at all
<marcan>
the current state is broken either way
<javierm>
but no with the refactor you do
<marcan>
and whether someone reported a bug or not makes no difference to how we fix it
<marcan>
it needs to be fixed either way
<marcan>
so if we want to be consistent, either we add 7 new helpers
<marcan>
or we remove broken formats that never worked
<javierm>
marcan: it's OK to just remove DRM_FORMAT_XRGB2101010? For M{1,2} would be native anyways right ?
<marcan>
I don't see why you would ever pick the former
<marcan>
javierm: no because that would break XRGB8888 conversion the way the helper logic is without my patch
<marcan>
and then if you add my patch you need the switch statement again to avoid advertising more new broken formats
<marcan>
and people *do* rely on XRGB8888 conversion for our platforms
<marcan>
why do y'all keep suggesting worse things :)
<javierm>
marcan: ah, so you need XRGB2101010 -> XRGB8888 ?
<marcan>
we need XRGB8888->XRGB2101010
<marcan>
(which I wrote the helper for)
<javierm>
marcan: but you will get that... since XRGB8888 will be still as the non-native format advertised
<marcan>
no, because the helper early-exits if the native format is not on the list
<marcan>
sigh...
<marcan>
seriously, actually think through the changes you're proposing, it doesn't work :)
<marcan>
I actually thought all of this through
<javierm>
marcan: yes, but that's something that we can fix
<marcan>
and... that is what my patch fixes
<marcan>
but then... you need to check for outright zero-helper formats in the driver to avoid over-reporting even more
<marcan>
which... is what that switch statement does
<marcan>
and then you're only a few steps away from the complexity of my patch, except my patch also fixes all the *other* over-reported formats
<marcan>
which you'd want to anyway
<marcan>
see what I'm getting at? :)
<pq>
javierm, I don't understand what you mean with userspace was able to pick any format, and after removing a broken format from the list, it can no longer pick a broken format. How is that not a good thing?
<marcan>
the entire point here is that yes, the current design/logic is kind of bad and broken, and needs a refactor
<marcan>
and the right time for that refactor is 6.2
<marcan>
and in the meantime we need to fix things given the current design, and that's what my patch does
<marcan>
it doesn't change any APIs, it won't cause merge conflicts with ofdrm
<marcan>
and ofdrm can be fixed to work well with both the current state of affairs and the state post that patch
<marcan>
then merged, then we refactor whatever we want
<marcan>
and we're done
<marcan>
and everyone is happy
swalker_ has joined #dri-devel
<marcan>
but if we start trying to play refactoring now in stable, that will break the ofdrm merge, and make reviewing harder
swalker_ is now known as Guest4198
<javierm>
marcan: my point was that your fix is more a refactor than a trivial fix for stable
<tzimmermann>
exactly this ^
<javierm>
pq: what I said that one can consider that the bug is that user-space isn't able to pick a format that's advertised and the fix is to make it work
<marcan>
it's as much of a refactor as is needed to actually fix the bugs, and doesn't change any APIs, break any current drivers, nor cause merge conflicts
<javierm>
even when is emulated
<marcan>
if you want to refactor a different way, you are introducing merge conflicts and changing APIs
<marcan>
that is strictly worse
<pq>
marcan, reading the email thread, looks like you can trivially just change the multiple array and a switch into a couple if-statements to make tzimmermann happy. And patch ofdrm while at it.
<javierm>
marcan: but adding the emulated format conversion is literally a few lines of code and self contained
<marcan>
sigh... and now we're looping back to adding a new format not being the answer
<marcan>
we already covered this
<javierm>
yes, we are adding another emulated format but such's life. We are advertising that anyways
<marcan>
I disagree
<marcan>
but I'm also getting tired of this
<marcan>
so I'm strongly leaning towards getting back to Asahi development and letting y'all fight this out
<javierm>
marcan: that's my opinion but we don't have to agree
<marcan>
it's not my users that regressed p
<marcan>
:p
<pq>
javierm, that does not make sense. If userspace picked that broken format before, it would have been broken. So userspace never picked the broken format.
<tzimmermann>
marcan, please read our format-conversion code and the email that pq just refered to. you can either write the format conversion or hide the logic in the helper. and both are less invasive than the current proposal
sarahwalker has joined #dri-devel
<pq>
tzimmermann, tbh, I don't understand how the current proposal is invasive. I see no difference between the original patch and my draft.
rahul_janga has quit [Ping timeout: 480 seconds]
<javierm>
marcan: haha, that's true. With my fedora developer hat I would merge your patch and unblock the release :)
<javierm>
marcan: but with my drm developer hat I disagree
<marcan>
I have a kid who can't log into his school wifi due to WPA-Enterprise being broken (known problem) and I'm much more inclined to get to fixing that ;)
swalker__ has quit [Remote host closed the connection]
<zamundaaa[m]>
javierm: in this case specifically, the only userspace program picking the broken format is KWin, which handles arbitrary format lists (like all userspace doing anything else than xrgb8888 should)
<tzimmermann>
pq, my two points with the current patch are: no ofdrm fix ; and the switch statement is unclear to me. that's why i'm asking for a central solution with clear documsntation. nothing else
<javierm>
zamundaaa[m]: yes I know. And we could just fix kwin to pick xrgb8888 and do the refactor in 6.2
<marcan>
sigh, okay, you get one more shot at this
<javierm>
zamundaaa[m]: I don't see the urgency to land a refactor in stable
<marcan>
I'm going to do things a different way, in the helper
<zamundaaa[m]>
KWin doesn't have enough information to pick xrgb8888
<marcan>
if you don't like it, I'm out
<tzimmermann>
i'm rfering to the patch on dri-devel BTW
<marcan>
the behavior will be identical to my current patch, just done differently
<marcan>
hopefully this will make tzimmermann happier?
rahul_janga has joined #dri-devel
<pq>
javierm, I don't understand why call this a refactor.
jlawryno has joined #dri-devel
<javierm>
pq: Ok, refactor may be a strech but it's not a trivial patch either
<pq>
it's a very short patch touching only one (well, and ofdrm) plave
<pq>
*place
Guest4198 has quit [Ping timeout: 480 seconds]
<javierm>
pq: yes, but it's a big change to simpledrm and not self contained
<pq>
javierm, do you think that the xrgb2101010-to-zrgb8888 conversion function is simpler than this patch?
<javierm>
pq: I believe yes, because it will only affect users that are picking that format
<javierm>
no other code path would be touched
<pq>
uh
<javierm>
I believe tzimmermann agrees too on that ^
<pq>
javierm, did you look at my draft?
<tzimmermann>
pq, take a look at that cited commit e08a99d005588f7f1d0647cdbc3368c98471fa6c it's self-contained and only affects user of that format combination. and i assume that a conversion helper within 6.1 would need even less code
<zamundaaa[m]>
javierm: that's a very bad argument
<tzimmermann>
that commit contains drm_fb_rgb565_to_xrgb8888_toio(). we recently generalized that code into a helper
<zamundaaa[m]>
Removing the format would also only affect userspace that would pick it
mszyprow has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
<daniels>
jannau: in my mind, the radius would be subtractive to the bounding-box area, not additive to it. like, the bounding box covers areas which are notched and areas which are _not_ notched because they're part of the corner. so if a compositor excludes just the rectangular area, it will always be safe (and can render a fixed background colour behind it). if it wants to be very smart, then it can take the corners into account in
<daniels>
order to render into the corner area.
<javierm>
zamundaaa[m]: removing yes, and if that was the patch I would ack it
<javierm>
zamundaaa[m]: but it's much more than that
<pq>
tzimmermann, but line count is completely secondary. You would be adding a whole new feature by this. Removing advertised formats that never worked to begin with is an insignificant change compared to adding support for new formats.
<javierm>
because we can't actually remove it, but instead have a policy on when has to be exposed or not and that's a big change IMO for stable
<javierm>
pq: it's not line count, but only affecting a specific code path and not touching others
<javierm>
it's certainly less risky
<tzimmermann>
what javier said
<pq>
javierm, it's affecting a code path that never worked. What else is removal affecting?
<tzimmermann>
from my perspective, we're not changing anything for userspace. so the conversion is less risky
<tzimmermann>
from kde's POV, simpledrm works. it's just that nothing is shown on the screen
<tzimmermann>
pq, i mean that kde doesn't know that the screen is dark
<pq>
tzimmermann, is that really how you determine if something "works"?
<tzimmermann>
it sees a format and tries to use it.
<tzimmermann>
it breaks for the user
<tzimmermann>
but not for userspace
<pq>
seriously? are you listening yourself?
<pq>
*to
<tzimmermann>
of course it's broken
<javierm>
marcan: ah, because drm_fb_build_fourcc_list() expects at least one format to be supported by the driver and native
<javierm>
marcan: yeah, that's a bug
<marcan>
that was an intentional but misguided way of avoiding returning nonsense conversions
<marcan>
and that is why my patch removes that check...
<marcan>
but anyway, I'm redoing this, and y'all better be happy with it :p
<tzimmermann>
maybe we're talking about differnt things? i'm refering to the kde output that is currently not visible on the screen
<marcan>
ofdrm still needs a change to not make things worse (the list of supported formats it presents should be basically just XRGB8888) and this still needs refactoring because there is an assumption baked into what I'm doing here
rahul_janga has quit [Ping timeout: 480 seconds]
<marcan>
but it's what I've got for a fix patch
<pq>
ok
<pq>
I very much regret ever asking in the first place.
<pq>
You do what you do, we in the userspace will top-up with driver-specific black-lists and whatnot in an attempt to keep performance up, since the kernel is hell-bent on lying to us.
<pq>
yes, I lost my patience now.
pq has left #dri-devel [goodbye]
<javierm>
pq: I think what tzimmermann is trying to say or at least how I see it is that we are breaking user-space by advertising a format that's not working
<javierm>
ah, he left...
<tzimmermann>
still there, kind of
<tzimmermann>
ah, pq
<javierm>
yeah
heat has joined #dri-devel
<daniels>
fwiw I agree with pq; if advertising those formats previously led to people being able to use those formats and have them work, then dropping them could be considered a regression, but that doesn't apply to when you just stop advertising support for something which didn't actually work
<javierm>
daniels: I agree with that. The problem is that we can't just drop it because that would break other users
<javierm>
daniels: so is either keep that and provide emulation or rework simpledrm adding some heuristic about when has to be advertised
<javierm>
IMO the former is less risky and more self contained
<javierm>
for stable I mean. For 6.2 we can do a bigger change
<daniels>
javierm: erm, sorry to revive this but I'm somewhat confused - right now XRGB2101010 (userspace) -> XRGB8888 (hardware) is advertised in the format list but non-functional. what's the case which would be broken by dropping the advertisement of 2101010 when only 8888 is available?
<zamundaaa[m]>
javierm: I challenge you to actually find any program using xrgb2101010 that can't handle the format not being advertised
imre has quit [Ping timeout: 480 seconds]
<marcan>
javierm: is your argument really that my patch is too complicated for stable and you would rather add a new format to stable?!
<marcan>
it's not a heuristic
<marcan>
it's a matrix
<daniels>
zamundaaa[m]: _technically_ that would be weston if someone explicitly configured 2101010 as the output format, because we won't in that case silently fall back to 8888
<marcan>
the same matrix of conversion helpers
<javierm>
daniels: because right now drm_fb_build_fourcc_list() (wrongly) assumes that the native format has to be listed by simpledrm
<javierm>
while it only should listen the emulated formats
imre has joined #dri-devel
<zamundaaa[m]>
daniels: heh, good to know. Practically noone would do that with simpledrm of course because the format is broken
<javierm>
marcan: it's more self contained, please take a look to the commit that tzimmermann referred above
Guest4139 is now known as DrNick
<javierm>
zamundaaa[m]: is not that, is that then it will break XRGB8888 -> XRGB2101010
<javierm>
due a bug in drm_fb_build_fourcc_list() as marcan pointed out
<javierm>
marcan: what would be the outcome of dropping XRGB2101010 in simpledrm and removing the break in drm_fb_build_fourcc_list() ?
<javierm>
more non-working formats listed ?
<marcan>
yes
<marcan>
sigh
<marcan>
let me finish this patch
<marcan>
and then I'm out
<zamundaaa[m]>
javierm: I'm not talking about commenting out the format. Obviously, you'd have to fix drm_fb_buuld_fourcc_list()
<zamundaaa[m]>
pq's not wrong with the driver specific blacklisting btw. If you backport such patches that cause performance regressions, that's what you'll end up with in userspace
<javierm>
zamundaaa[m]: yes and fixing drm_fb_buuld_fourcc_list() may be a smaller fix
<karolherbst>
ishitatsuyuki: you might want to keep the new lines though
<ishitatsuyuki>
karolherbst: which newlines? I thought I added the missing trailing newline in revision 3
<karolherbst>
ohh, right.. might want to move the fixes into the previous commits though
<ishitatsuyuki>
ah, oof, I'm dumb
<jenatali>
ishitatsuyuki: I'm a fan in theory. I'd like to try it on MSVC :)
<ishitatsuyuki>
nice to hear, looking forward to the results :)
fab has quit [Quit: fab]
<tzimmermann>
javierm, sorry, i didn't want to make pq ragequit
rsalvaterra has quit []
<javierm>
tzimmermann: I think we can share the blame really, but I also didn't want that
rsalvaterra has joined #dri-devel
jlawryno has quit [Ping timeout: 480 seconds]
<marcan>
tzimmermann: v2 on the list, that's all I got. if you don't like this one, I'm checking out of this particular rabbit hole ;)
yuq825 has quit []
<tzimmermann>
marcan, i'll take a look. but it's not about what i like. if we change the list of exported formats, we're changing userspace's view on the graphics output. maybe i'm overly careful here, but i don't take this lightly. especially for something that is supposed to go into stable. by simply implementing the conversion helper now, nothing will change for userspace. and we'd have time to properly fix everything for one
<tzimmermann>
of the next major releases. hopefully this explains my position
<marcan>
... no, it really doesn't, because most of your argument thus far has been about refactoring and whether the changes should be in the helper or not and what about ofdrm
<marcan>
I already explained how the correct course of action for stable is to drop the regression by dropping the broken format, because by definition nothing can be relying on a broken format already, and introducing a helper actually creates a performance regression, and ffs you already made pq ragequit over this, please don't make me ragequit too
<MrCooper>
why are we still even talking about fixing the broken format, instead of dropping it :(
<marcan>
MrCooper: I have no idea
<marcan>
tzimmermann: you have two options, v1 or v2. I am not writing a new conversion helper.
mrkajetanp has joined #dri-devel
<MrCooper>
it was pretty clearly a bad idea many pages of scrollback ago
<javierm>
for me is more about keeping the fix self contained and with minimal changes to avoid risk when pushing to stable, and that option is the conversion helper
<javierm>
but I will stop arguing for that to avoid marcan to rage quit :)
<marcan>
I broke it, v1 and v2 are my two suggestions to fix it, if people don't like them they can write their own fix. sorry, I'm kind of at the limit of my patience now too, I'm going to go figure out what's wrong with WPA-Enterprise and then sleep. maybe, because I went into this expecting a 30 minute discussion + fix + testing cycle, and it has now been **5 hours** and I was not planning on spending ...
<marcan>
... that much time arguing about DRM format conversions today. sigh.
<MrCooper>
it doesn't really "avoid risk" though, it increases the risk of user space actually relying on that format
<javierm>
marcan: sure, and thanks a lot for your patches!
<javierm>
MrCooper: it's not a small change and touches code paths used by any simpledrm user
<javierm>
but it folks feel to strong about not adding an emulated format (that might even be dropped in a future release) then I think that v2 is a better option and more self contained
mrkajetanp has quit [Remote host closed the connection]
Akari has joined #dri-devel
<daniels>
yeah, I definitely feel very very strongly about not establishing a precedent of DRM 'helpfully' performing expensive operations without explicit user opt-in
mrkajetanp has joined #dri-devel
<javierm>
daniels: fair
<daniels>
sorry :) I can see how it would make sense locally with a simpledrm lens on, but I think more generally it's just going too far against the rest of the ecosystem
<javierm>
daniels: yeah. I do agree with pq in fact that anything but native + xrgb8888 doesn't make sense and it's worth to attempt dropping all that
<javierm>
my gut feeling is that nobody would care of anything else
<daniels>
javierm: and if they do care about it, tell them they'll have to fight for it on #dri-devel :D
<javierm>
daniels: haha, indeed
fab has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
robclark: how is PERSISTENT|COHERENT supposed to work on tilers?
<robclark>
not sure offhand, I think if you are trying to race the GPU rendering it has to be somehow undefined behavior, tiler or not
<robclark>
but you'll have to ask a spec lawyer
<alyssa>
- If MAP_COHERENT_BIT is set and the client performs a write, then in
<alyssa>
subsequent commands the server will see the writes.
<alyssa>
this is the bit of spec text I can't wrap my head around
<tango_>
so changes to the mapped area should be visible on device on the command following the write?
<alyssa>
that's how I read that text
<alyssa>
and that is.... problematic
<tango_>
is this supposed to be supported by all hardware, or just those that have some particular properties?
<tango_>
like coarse grained vs fine grained atomis inn opencl, to wit
<robclark>
time doesn't work the way you think it does for tilers ;-)
<alyssa>
robclark: right, that's what I'm struggling with
<alyssa>
the spec text makes sense in the context of a system-coherent IMR
DemiMarieObenour[m] is now known as DemiMarie
<alyssa>
none of this makes any sense for a non-coherent tiler
<zmike>
alyssa: fwiw in zink there's explicit vkFlushMappedMemoryRanges calls on gpu submission any time persistent buffers are used
<alyssa>
(which includes some Malis)
<MrCooper>
why is that problematic? Note that all it says is writes are visible in later commands, e.g. it doesn't say writes aren't visible in earlier commands
<alyssa>
MrCooper: oh gosh
<alyssa>
time..
<robclark>
heh, lol
<alyssa>
zmike: The Panfrost kernel driver invalidates and flushes caches right before submitting work and right after finishing work
<alyssa>
Whether there's coherency *while* executing is hardware dependent, but generally not
<tango_>
yeah pretty sur that what happens to earlier commands is undefined
<alyssa>
otoh the execution doesn't even happen until flush time, and, umm
<daniels>
alyssa: wouldn't that also preclude tc?
<alyssa>
daniels: How so?
mszyprow has joined #dri-devel
<tango_>
alyssa: depends is whether in subesequenly ENQUEUED or EXECUTED commands
<tango_>
if the spec actually requires to be visible to subsequently enqueued commands, it might require syncing before the flush
<tango_>
(but that's probably not what is meant)
<alyssa>
yes, I am definitely wondering if what is meant is not what is written ...
<MrCooper>
my interpretation of "later commands" would be "commands generated by GL API calls after the write"
<alyssa>
right, ok
<alyssa>
there's another ... questionable interpretation I can give
<alyssa>
that GPU work completely instantly when it is flushed out
<alyssa>
so then the GPU writes are visible to the CPU immediately
<alyssa>
for some noisy value of immediately ;-)
<tango_>
actually no
<alyssa>
no?
<tango_>
for that direction a fence is explicitly required
<daniels>
yeah, I guess there's no real hazard with CPU writes against earlier (still-queued) commands, since they're not guaranteed to complete until after glFinish/eglClientWaitKHR anyway? and against later commands, you either need to be globally coherent in order to implement MAP_COHERENT (reasonable), or clflush all CPU-mapped coherent ranges on cmd flush
<tango_>
> If MAP_COHERENT_BIT is set and the server does a write, the app must call FenceSync with SYNC_GPU_COMMANDS_COMPLETE (or Finish). Then the CPU will see the writes after the sync is complete.
<alyssa>
right ok
<alyssa>
and conversely we have
<alyssa>
- If MAP_COHERENT_BIT is set and the client performs a write, then in
<alyssa>
subsequent commands the server will see the writes.
<tango_>
so curiously the “no action required” is only for cpu to device, conversely you need a fence
<alyssa>
subsequent commands, not the same command already running
<alyssa>
and if there are subsequent commands there'll be a flush later for it all to work out
<tango_>
yeah, it's probably commands enquued after the writ
<alyssa>
what I'm struggling with is, supposing we supported preemption,
jkrzyszt has joined #dri-devel
<alyssa>
enqueueing a long running compute kernel
<alyssa>
that polls shared memory and uses the polled values
<alyssa>
and that shared memory is mapped on the CPU as PERSISTENT|COHERENT
<tango_>
(well this was from nvidia so no preemption ;-))
<alyssa>
The spec seems to require that any writes from the CPU must be immediately visible to the compute kernel on the GPU
<alyssa>
and that is not something I can guarantee, I doubt your hardware can either
<tango_>
I don't think this is required
<alyssa>
It's a stupid case that probably wasn't intended? but still
<alyssa>
The literal reading of the text implies it
tzimmermann has quit [Quit: Leaving]
<tango_>
not if the long running compute kernel was enqueued before the write
<tango_>
iow you can't “signal” a running kernel from the host using this extension
<tango_>
for that you probably need something like opencl fine-grained atomics
<alyssa>
right, okay
<tango_>
not sure if opengl has something like that though
<alyssa>
so this is all based around a timeline that has no basis in reality in tilers
<alyssa>
I can live with that
<daniels>
yeah, 'in subsequent commands' seems quite clear to me?
<tango_>
no, if the rendering was started before the change my guess would be that what the tiler sees after the change isn't defined
<tango_>
it may or may not see the change
<alyssa>
OK. I feel comfortable with this then I think. Maybe.
<alyssa>
alternatively i should take the yeet approach
<alyssa>
doesn't break any piglits? great CAP set
<tango_>
lol
<daniels>
alyssa: 10000% improvement on dolphin too afaik
<alyssa>
daniels: yeah with this extension I can play Mario Kart at 700fps on mali-55
<alyssa>
it's great
<alyssa>
My problem with supporting console emulators (features or perf) is that, homebrew aside, there is no reasonable legal way for me to test hem
<alyssa>
I'm not investing in a DVD ripper to appease rude users
<daniels>
phew, someone had to take the performance mantle whilst zmike takes that couple of months off to ~~switch to his alter ego as Seamus the WWE wrestler~~ relax
<zmike>
THE TORCH HAS BEEN PASSED
<alyssa>
muscle emoji
<zmike>
yesssss it is done.
<alyssa>
I still don't understand what I'm doing, setting the CAP
<alyssa>
what specific requirements does this impose on mesa? or the kernel driver? or the hardware?
<alyssa>
should I set this for asahi too?
<alyssa>
do we ever need the CAP? can this be supported on every driver?
MrCooper has quit [Quit: Leaving]
<alyssa>
I guess yes on Asahi, because there are no explicit sync ioctls needed, it's coherent at flush boundaries like Mali (it has to be)
MrCooper has joined #dri-devel
<danvet>
you just pipeline nothing at all?
* danvet
confused
<alyssa>
if I do so, drivers that still won't support it: d3d12, softpipe, etnaviv, i915g
<alyssa>
softpipe is probably just an omission because llvmpipe does support
<alyssa>
and this all seems like it ought to be trivial for swrasts
<daniels>
alyssa: presumably you either have to allocate the coherent buffer from an uncached range, or limit it to hardware which has CPU/GPU cache coherency, right?
<Lyude>
jadahl: are the MST issues with amdgpu?
<jadahl>
Lyude: intel
<alyssa>
daniels: I guess so? But lack of sync ioctls => cache coherency on render pass boundaries
<jadahl>
Lyude: i need to plugin-plugout 2-3 times for the monitor to light up since I booted my 6.0.0rc2+ kernel
<jadahl>
funny thing is if I enable drm debug logging, it's harder to reproduce
<Lyude>
jadahl: is that the latest one? I thought we were on 6.1.0 now
<alyssa>
etnaviv should be able to support but its resource code is... complicated
<jadahl>
Lyude: I can rebase and try if you think there are fixes that I don't have
<alyssa>
i915g looks like it should support for the same reason as panfrost
<Lyude>
jadahl: we definitely had one MST fix for Intel that caused some problems in ci iirc
<Lyude>
erm, fixed
<alyssa>
d3d12 is the only one I'm unsure of
<alyssa>
jenatali: Can D3D12 support PERSISTENT|COHERENT?
<Lyude>
jadahl: can find you the patch if you want
<jadahl>
Lyude: no worries, i'll rebase and test
sarahwalker has quit [Remote host closed the connection]
<tango_>
so hm when opencl on my rx580 doesn't work failing with this message, is there something I can do or is it a distro packaging issue?
<tango_>
fatal error: cannot open file '/usr/lib/clc/polaris10-amdgcn-mesa-mesa3d.bc': Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM15.0.3' Reader: 'LLVM 15.0.3')
<tango_>
Mesa 22.2.2 as shipped in debian unstable on 5.19.6
Duke`` has joined #dri-devel
<psykose>
i assume whatever is reading them needs to disable opaque pointers too, as for 22.2.2 they are disabled when building with llvm 15
<jenatali>
alyssa: Yes
<jenatali>
For a while we had plans to support a QC chip that didn't support coherent, which is why our Map/Unmap methods have range hints for cache control, but they didn't build a driver for that part and the ones that are supported do have coherent caches
<alyssa>
see the past hour of logs in #dri-devel in which the spec lawyers here convince me that supporting that is cool and good
<alyssa>
seemingly, as long as you don't need syncs in your transfers (i.e. you can just write resources and use them later and vice versa) it should be ok to support... probably
<alyssa>
which seems to cover everybody
<alyssa>
so hoping to bulldoze the CAP if so
<alyssa>
but also I don't really care
<alyssa>
it's now lunch time, that's what i care about now (:
<jenatali>
Sounds good to me. If CI doesn't blow up then go for it - if CI does blow up then I can take a closer look
<alyssa>
jenatali: see last statement
<jenatali>
Heh fair enough. Looks like it's part of GL4.4 so we'd be getting around to flipping it on at some point anyway. I assume it'll just be free
mrkajetanp has quit [Remote host closed the connection]
<lynxeye>
alyssa: Aside from CPU caching coherent also requires that you don't have shadow buffers for the resources, but map them directly. etnaviv has linear shadows for tiled buffers and does the up-/download to the real tiled resource visible to the GPU via separate engines on the GPU, which require explicit flushing, which isn't compatible with coherent.
<jenatali>
lynxeye: I presume that's only for textures, not for buffers?
<lynxeye>
jenatali: right, textures and render targets
<jenatali>
Right, this discussion is strictly about buffers I'm pretty sure
Company has joined #dri-devel
<zmike>
yep
<tango_>
what happens if a texture is buffer-backed?
tursulin has quit [Ping timeout: 480 seconds]
<emersion>
question about tilers: we have EGL_KHR_partial_update for EGLSurface, but i use FBOs. would it make sense to have a similar ext for FBOs?
<lynxeye>
tango_: iirc buffer textures are always one dimensional and thus shouldn't require tiling. But then making sure that those are always mapped directly is exactly the reason why I want to take a deep look at the etnaviv map code first, before enabling the cap.
jkrzyszt has quit [Remote host closed the connection]
mszyprow has quit [Ping timeout: 480 seconds]
sarahwalker has joined #dri-devel
<alyssa>
emersion: which tilers are you specifically interested in?
<alyssa>
IIRC the only Mesa driver that can take advantage of that extension is Panfrost, and even then only on older Malis (Midgard era) since there's a hardware thing that replaces(?) it on newer Malis
<alyssa>
and even then I don't remember seeing phenomenal gains
<emersion>
ah, okay, good to know!
<alyssa>
The ext is a nice idea in theory
<alyssa>
and we have it plumbed into mesas
<emersion>
not interested in a specific hw, just heard from daniels that it's Nice
<alyssa>
I just don't know what drivers can *do* with that information
rgallaispou has joined #dri-devel
<alyssa>
With no extension on the older hardware, EGL_BUFFER_PRESERVED requires a full blit at the start of the frame
<daniels>
alyssa: v3d could use it as well
<alyssa>
With the extension, we can blit only to the parts of the frame that actually changed and avoid writing out the rest (rounding up the rectangles the compositor gives to tile boundaries)
<alyssa>
Without the extension on the newer hardware (bifrost onwards), there's a hardware feature to avoid writing "clean" tiles -- tiles that have not been drawn to --
<alyssa>
and critically, a way to blit only to tiles that actually are not clean
<alyssa>
where the PRESERVED back blit is specially considered as "clean"
<alyssa>
which means regardless of the extension, we get a comparable optimization for free
<alyssa>
and IDK what to do otherwise with the extension info
<alyssa>
daniels: good to know +1
flto has quit [Remote host closed the connection]
mbrost has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
<alyssa>
OA
<alyssa>
nF
<alyssa>
V
<alyssa>
I mean, looks like lima has it wired up now too, nice :)
aravind has quit [Ping timeout: 480 seconds]
flto has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
frieder has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
kem has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
emersion: fyi for KWin I'd be interested. Gbm surfaces make our drm backend more complicated than necessary, and we can't currently use gbm buffers with fbos because we want the efficiency gains from EGL_KHR_partial_update
<zamundaaa[m]>
emersion: thanks, will keep an eye on that
alyssa has quit [Quit: leaving]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
jljusten has quit [Ping timeout: 480 seconds]
jljusten has joined #dri-devel
guru_ has quit [Read error: No route to host]
oneforall2 has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mbrost has joined #dri-devel
ngcortes has joined #dri-devel
Haaninjo has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
<jenatali>
Hm, does mesa/st have any kinds of heuristics for opportunistic flushes?
<jenatali>
One of these CL/GL test cases creates and initializes a ton of large cube textures, then deletes them, but never flushes, meaning we never actually get a chance to deallocate the memory
mbrost has quit [Ping timeout: 480 seconds]
<jenatali>
Thinking I might have to switch from the default subdata handlers to track this in our driver to flush when so much memory is used
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
mbrost has quit [Ping timeout: 480 seconds]
<gpiccoli>
hi folks, not sure if this is the proper place to ask (apologies if not!)...but today I registered on gitlab (gitlab.freedesktop.org) and never received the confirmation email. Maybe some maintenance ongoing ?
<jenatali>
gpiccoli: #freedesktop is what you want, and I think I saw the admins there saying it takes ~30 minutes to get the email
moa has joined #dri-devel
<daniels>
gpiccoli: the confirmation can sometimes go to spam too, so I've just marked you as confirmed now
srslypascal is now known as Guest4225
<gpiccoli>
thanks you both! And awesome news daniels =)
srslypascal has joined #dri-devel
<gpiccoli>
it's not on my spam BTW, but I just received both emails (the "welcome" one plus the..confirmation heh)
<karolherbst>
daniels: ohh.. right.. We wanted to point out on the login page to use the external login things. Mind adding something like "Please use the 'Sign in with' feature below, otherwise when...." in proper english to it? Might help
Guest4225 has quit [Ping timeout: 480 seconds]
bluebugs has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
jani has quit []
jani has joined #dri-devel
<DemiMarie>
Is it possible to go from a UMF to something that works with poll(), perhaps via a futex-like syscall?
jlawryno has joined #dri-devel
mszyprow has joined #dri-devel
leo60228- has joined #dri-devel
jlawryno has quit [Ping timeout: 480 seconds]
leo60228 has quit [Ping timeout: 480 seconds]
sigmaris_ has joined #dri-devel
<emersion>
DemiMarie: UMFs dont really exist atm
srslypascal has quit [Quit: Leaving]
<DemiMarie>
emersion: then will it be possible? because the alternative (having to busy-poll) seems horrible for battery life
<emersion>
there is sync_file, and drm_sybcobj
<DemiMarie>
Of course one wants to be able to batch as many notifications as possible.
<emersion>
DemiMarie: everything is pretty much still TBD at this point
<DemiMarie>
emersion: what happened to the “turn dma-bufs into something pollable” patchset?
<emersion>
dmabufs are already pollable
<emersion>
there is also an ioctl to export a sync_file from a dmabuf
leo60228- has quit [Ping timeout: 480 seconds]
sigmaris has quit [Ping timeout: 480 seconds]
<DemiMarie>
So the patch set got applied?
srslypascal has joined #dri-devel
<emersion>
yes
anholt has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
dakr has quit [Read error: No route to host]
dakr has joined #dri-devel
fab has quit [Quit: fab]
jewins has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
Akari has joined #dri-devel
srslypascal has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<jenatali>
There we go, passing all the test cases of the CL/GL interop CTS tests individually... but I'm still hitting OOM trying to run them all together because the test doesn't flush GL enough
JohnnyonFlame has joined #dri-devel
srslypascal is now known as Guest4235
srslypascal has joined #dri-devel
Guest4235 has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Read error: Connection reset by peer]
<Kayden>
we'd disabled nir_opt_access's ability to infer non-readable (writeonly) on images because of a bug, but it seems like we can solve it easily by moving the pass order
<Kayden>
seems a bit too easy...
<jenatali>
Ah... PIPE_CAP_MAX_TEXTURE_UPLOAD_MEMORY_BUDGET is what I needed
<FLHerne>
Zink presentation complained about there being a hundred pipe caps that might be useful if anyone documented what they're for; seems accurate so far
lemonzest has quit [Quit: WeeChat 3.6]
<jenatali>
IMO the problem isn't a lack of documentation, it's just the fact that there's too many
<jenatali>
I don't have time to sit and read the docs for a giant list of caps on the off chance one might solve a problem I don't know that I have :)
<FLHerne>
PIPE_CAP_DO_WHAT_I_MEAN
<karolherbst>
could just enforce certain behavior, like lowered uniforms...
<karolherbst>
(and kill of load_uniform for good)
<karolherbst>
though I guess there are always reasonable reasons to have those caps or certain different paths
<Kayden>
in the old days pipe caps were more tied to hardware limitations or desire for things to work a certain way for a particular piece of HW
<Kayden>
now a lot of them seem to be "I implemented this in my driver, and nobody else / only a few people have gotten around to updating"
<Kayden>
which is totally fair - somebody's got to write the new cool thing first, and it's not reasonable to expect them to go through and update all the other drivers. there are a lot more of them than there used to be. also in some cases the developer's employer may not even approve of them working on certain drivers
<jenatali>
Yep pretty much
<Kayden>
but it'd probably be good if we identified a set of those and made an effort across the project to get everything working in the new cool way and then dropped them
<karolherbst>
yeah... would probably make a lot sense to start with caps not supported by very few drivers, but I wouldn't know which one those are anyway :)
<karolherbst>
but I also was thinking move more of the hw limits into structs, because using Caps for them is just pure pain
<karolherbst>
just look at the compute cap mess
<Kayden>
mesamatrix for pipe caps would be great
<karolherbst>
it makes no sense doing it this way
<jenatali>
:P
<karolherbst>
I'll probably clean up some of hte compute caps soonish, because I need to change gallium even more, lucky me
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
maybe we should sort CAPs by amounts of grep hits and deal with the ones being used less often
<jenatali>
Huh, apparently approving a MR is also something that only developers can do
danvet has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
vliaskov has quit [Remote host closed the connection]
<deathmist>
particularly I'd be interested if you also see https://gitlab.freedesktop.org/mesa/mesa/-/issues/7555 (freedreno: X11/XWayland on Adreno 540 freezes updating screen entirely) or can make it drm_msm hangcheck by simply leaving the game running after entering a world for some while
YuGiOhJCJ has joined #dri-devel
<karolherbst>
uhh... nir_shader_gather_info only works reliable after system values got lowered...