<lina>
There is a very cursed hack involved since GPU TLB (or cache?) invalidation is still broken or not synced properly, but it works stably with the hack!
<mupuf>
lina: congrats! I can foresee some gears spinning during your presentation :p
<lina>
I think I'm already doing better than that ^^
Duke`` has quit [Ping timeout: 480 seconds]
<mupuf>
hehe, looking forward to it :)
<airlied>
lina: there is nothing better than gears
Company has quit [Quit: Leaving]
itoral has joined #dri-devel
pochu has joined #dri-devel
<lina>
airlied: eglgears was working yesterday already! Full GNOME took a bit longer ^^
aravind has quit [Read error: Connection reset by peer]
<pq>
mdnavare, no, I was not asking about VRR freq outside VRR range. I was asking from the oldchdool fixed-freq mode lines vs. monitor Horz/Vert freq limits from the VGA era.
sdutt has quit [Ping timeout: 480 seconds]
<pq>
bl4ckb0ne, extension functions are not (supposed to be) exported.
<pq>
*oldschool
<pq>
mdnavare, I believe the kernel will filter the mode list against the monitor Horx/Vert freq limits, but what I don't know if it stops userspace from programming a custom modeline that exceeds those limits (and has physically destroyed monitor hardware in the CRT era).
<pq>
*Horz
<pq>
It's wasn't Linux, but I've seen a too high video mode kill a monitor. IIRC I also fixed it (or attempted to fix it) by replacing the flyback transistor.
linkmauve has quit [Ping timeout: 480 seconds]
chipxxx has quit [Read error: Connection reset by peer]
elongbug has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
<jfalempe>
tzimmermann, I sent a patch to add support for Atomic gamma lut for the ast driver.
<jfalempe>
but I only tested it remotely, so I didn't see if it actually change the gamma on a VGA screen.
anshuma1 has joined #dri-devel
kts has quit [Quit: Leaving]
fab has quit [Quit: fab]
kts has joined #dri-devel
<dj-death>
anybody running into 504 errors from gitlab fdo?
<pq>
dj-death, that's maintenance WIP
apinheiro has joined #dri-devel
<dj-death>
pq: ah thanks
kts has quit [Quit: Konversation terminated!]
Haaninjo has joined #dri-devel
pallavim has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
vliaskov has joined #dri-devel
anshuma11 has joined #dri-devel
anshuma12 has joined #dri-devel
anshuma12 has quit [Read error: Connection reset by peer]
anshuma1 has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
chipxxx has joined #dri-devel
anshuma1 has joined #dri-devel
anshuma11 has quit [Ping timeout: 480 seconds]
<tzimmermann>
jfalempe, thanks. i'll give it a try
chipxxx has quit []
<tzimmermann>
jfalempe, i'm looking at the patch. couldn't you simply copy the code from mgag200?
chipxxx has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
kts has joined #dri-devel
kts has quit []
itoral has quit [Remote host closed the connection]
kts has joined #dri-devel
dos1 has quit [Quit: Kabum!]
dos1 has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
kts has quit [Quit: Leaving]
kts has joined #dri-devel
kts has quit []
kts has joined #dri-devel
kts has quit []
linkmauve has joined #dri-devel
<jfalempe>
tzimmermann, hum I think I copied a lot from mgag200. ast is simpler because it doesn't support 16bits colors.
<jfalempe>
or you mean having a separate function to set the default if no data are provided ?
<robert_mader>
Hi - I'm currently facing some issues regarding EGL_EXT_image_dma_buf_import_modifiers and llvmpipe on a CI. From what I understand, llvmpipe should never advertise this extension, right? I do see cases though were it is - and I suspect it to happen when a "hardware" (VirtIO) driver fails to initialize properly and the GL context ends up being provided by llvmpipe. Is that a known case? And does anyone have a hint what could
<robert_mader>
way to detect that? Checking for `EGL_MESA_device_software`?
<anshuma1>
airlied: could you pleae help on that.
bmodem has quit [Ping timeout: 480 seconds]
<daniels>
robert_mader: src/gallium/frontends/dri/dri2.c is you - dri2_init_screen_extensions() will set the extension if PIPE_CAP_DMABUF is set
<tzimmermann>
jfalempe, thank you
anshuma1 has quit [Read error: Connection reset by peer]
<jfalempe>
tzimmermann, ast also support "CRM_FORMAT_C8" for primary plane, this is 8bit monochrome ?
<jfalempe>
so probably can use the same as RGB888 for gamma value ?
<tzimmermann>
jfalempe, it's a 256-color palette
<tzimmermann>
the palette will be taken from the same values as the gamma table
<tzimmermann>
so the code for xrgb8888 can be uses as-is to fill the table
<jfalempe>
ok thanks
<tzimmermann>
TBH, i have no idea is C8 really works in practice. no one uses these formats today
<tzimmermann>
s/is/if
apinheiro has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
ella-0[m] has quit [Write error: connection closed]
unrelentingtech has quit [Write error: connection closed]
doras has quit [Write error: connection closed]
DemiMarieObenour[m] has quit [Write error: connection closed]
ralf1307[theythem][m] has quit [Write error: connection closed]
reactormonk[m] has quit [Write error: connection closed]
Strit[m] has quit [Write error: connection closed]
onox[m] has quit [Write error: connection closed]
jekstrand[m] has quit [Write error: connection closed]
kunal_1072002[m] has quit [Write error: connection closed]
Anson[m] has quit [Write error: connection closed]
egalli has quit [Write error: connection closed]
cwfitzgerald[m] has quit [Write error: connection closed]
Sumera[m] has quit [Write error: connection closed]
michael5050[m] has quit [Write error: connection closed]
MatrixTravelerbot[m]1 has quit [Write error: connection closed]
Newbyte has quit [Write error: connection closed]
underpantsgnome[m] has quit [Write error: connection closed]
Guest1631 has quit [Write error: connection closed]
Andy[m] has quit [Write error: connection closed]
arisu has quit [Write error: connection closed]
DavidHeidelberg[m] has quit [Write error: connection closed]
Tooniis[m] has quit [Write error: connection closed]
masush5[m] has quit [Write error: connection closed]
robertmader[m] has quit [Write error: connection closed]
gagallo7[m] has quit [Write error: connection closed]
GeorgesStavracasfeaneron[m] has quit [Write error: connection closed]
hasebastian[m] has quit [Write error: connection closed]
nielsdg has quit [Write error: connection closed]
tintou has quit [Write error: connection closed]
znullptr[m] has quit [Write error: connection closed]
zamundaaa[m] has quit [Write error: connection closed]
Weiss-Fder[m] has quit [Write error: connection closed]
tleydxdy has quit [Write error: connection closed]
moben[m] has quit [Write error: connection closed]
kunal_10185[m] has quit [Write error: connection closed]
AlexisHernndezGuzmn[m] has quit [Write error: connection closed]
naheemsays[m] has quit [Write error: connection closed]
Mis012[m] has quit [Write error: connection closed]
Labnan[m] has quit [Write error: connection closed]
mripard has quit [Write error: connection closed]
danylo has quit [Write error: connection closed]
tomba has quit [Write error: connection closed]
neobrain[m] has quit [Write error: connection closed]
hch12907 has quit [Write error: connection closed]
bylaws has quit [Write error: connection closed]
xerpi[m] has quit [Write error: connection closed]
martijnbraam has quit [Write error: connection closed]
yshui` has quit [Write error: connection closed]
RAOF has quit [Write error: connection closed]
pushqrdx[m] has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
eyearesee has quit [Write error: connection closed]
PiGLDN[m] has quit [Write error: connection closed]
x512[m] has quit [Write error: connection closed]
viciouss[m] has quit [Write error: connection closed]
r[m] has quit [Write error: connection closed]
undvasistas[m] has quit [Write error: connection closed]
knr has quit [Write error: connection closed]
sigmoidfunc[m] has quit [Write error: connection closed]
pac85[m] has quit [Write error: connection closed]
nyorain[m] has quit [Write error: connection closed]
halfline[m] has quit [Write error: connection closed]
jasuarez has quit [Write error: connection closed]
ambasta[m] has quit [Write error: connection closed]
robertfoss[m] has quit [Write error: connection closed]
Dylanger has quit [Write error: connection closed]
Soroush has quit [Write error: connection closed]
Ella[m] has quit [Write error: connection closed]
colemickens has quit [Write error: connection closed]
frytaped[m] has quit [Write error: connection closed]
cleverca22[m] has quit [Write error: connection closed]
kallisti5[m] has quit [Write error: connection closed]
bluepenquin has quit [Write error: connection closed]
heftig has quit [Write error: connection closed]
YaLTeR[m] has quit [Write error: connection closed]
Guest1623 has quit [Write error: connection closed]
LaughingMan[m] has quit [Write error: connection closed]
cmeissl[m] has quit [Write error: connection closed]
dcbaker has quit [Write error: connection closed]
jenatali has quit [Write error: connection closed]
T_UNIX has quit [Write error: connection closed]
JosExpsito[m] has quit [Write error: connection closed]
Mershl[m] has quit [Write error: connection closed]
dafna33[m] has quit [Write error: connection closed]
Vin[m] has quit [Write error: connection closed]
mairacanal[m] has quit [Write error: connection closed]
kusma has quit [Write error: connection closed]
KunalAgarwal[m][m] has quit [Write error: connection closed]
Guest1647 has quit [Write error: connection closed]
sjfricke[m] has quit [Write error: connection closed]
zzoon[m] has quit [Write error: connection closed]
kunal10710[m] has quit [Write error: connection closed]
gdevi has quit [Write error: connection closed]
ramacassis[m] has quit [Write error: connection closed]
chema has quit [Write error: connection closed]
chipxxx has quit [Read error: No route to host]
arisu has joined #dri-devel
devilhorns has quit []
cef has quit [Quit: Zoom!]
chipxxx has joined #dri-devel
cef has joined #dri-devel
<robert_mader>
daniels: thanks. Do you happen to know whether it's a possible that X11 EGL falls back to llvmpipe while previously having initialized and advertised EGL extensions from the hardware device? Do you recall ever having seen that? (I think I do on some broken setups - but only with EGL on X11)
<daniels>
robert_mader: I can't for the life of me imagine how that would happen, no
<daniels>
robert_mader: but I will note that PIPE_CAP_DMABUF is true for llvmpipe, so advertising dmabuf import & the modifier extension _is_ expected
<javierm>
tzimmermann: I'll review the udl series you mentioned yesterday but before that I've a question from reading the cover-letter
<javierm>
tzimmermann: in patch #9 you will get rid of drm_atomic_helper_damage_merged() and instead use a damage iterator, it's the second time you do on a driver (first was simpledrm)
<javierm>
tzimmermann: should using drm_atomic_helper_damage_merged() be something that other drivers would like to avoid too then ?
<tzimmermann>
javierm, i think so
<robert_mader>
daniels: ok, then I need to check where it usually gets disabled (it does, see e.g. `eglinfo` or running any app with `LIBGL_ALWAYS_SOFTWARE`)
<tzimmermann>
but i grepped for the use of the iterator vs. merged. and merged is used more often by far IIRC
<tzimmermann>
i guess that everyone simply copied pre-existing code and therefore took damage_merged as well
<javierm>
because notice that the convention is to use the helper
<daniels>
robert_mader: swrast is Special
<daniels>
robert_mader: so it depends on how it gets initialised ...
<tzimmermann>
javierm, i once received a patch from jfalempe that implemented iterators for mgag200. she said that it improves the performance compared to merging. since then, i consider damage_merged to be obsolete
<tzimmermann>
all the hardware that uses damage_merge is at least as slow as mgag200. so it probably sees similar effects
<tzimmermann>
therefore, merging damage only seems to make sense if there are several overlapping areas that would otherwise be copied multiple times.
<tzimmermann>
that's something that userspace can detect more easily that the driver. so userspace should merge the damage area accordingly
<javierm>
tzimmermann: got it. Then probably we should provide a helper that gets as an argument a function that handles rect damages
<javierm>
and also get the old and new plane state
<javierm>
tzimmermann: similar to how drm_atomic_helper_damage_merged() does but not using the whole area
<tzimmermann>
javierm, i have not yet found a good helper for that. so far, all the drivers appear to be slightly different. maybe once they are all converted, a helper emerges
<javierm>
tzimmermann: fair
<tzimmermann>
the thing is that some, like udl and simpledrm, have a small area where the virtual primary plane can be moved around
<tzimmermann>
others, such as mgag200, use the hardware's line offset/stride register to implement virtual planes
<tzimmermann>
so far, it's all a bit different from each other
<javierm>
tzimmermann: is the former due the usage of shadow-buffered primary planes ?
fab has joined #dri-devel
<tzimmermann>
yes
<javierm>
tzimmermann: got it
<tzimmermann>
but also the later
<tzimmermann>
it's the way in which these virtual screen sizes are implemented
<javierm>
tzimmermann: I see
<javierm>
tzimmermann: Ok, let's think about a helper later then. I just wanted to understand this before looking at your patch-set in detail
<tzimmermann>
sure, np
<jfalempe>
tzimmermann, yes, I've seen this on mgag200, when you move the cursor on one corner, and there is an animation on the opposite corner, merging damage region is clearly not a good strategy.
<tzimmermann>
haha, yes
apinheiro has joined #dri-devel
<javierm>
tzimmermann: I'll then drop drm_atomic_helper_damage_merged() in the ssd130x driver too
<tzimmermann>
ok
<javierm>
I use that driver as a playground to learn more about DRM :)
<tzimmermann>
:)
heat_ has joined #dri-devel
apinheiro has quit [Quit: Leaving]
bmodem has joined #dri-devel
rasterman has joined #dri-devel
chipxxx has quit [Read error: Connection reset by peer]
<karolherbst>
yeah well.. if the LLVM IR is empty...
<karolherbst>
heh.. instcombine kills the entire shader
chipxxx has joined #dri-devel
Company has joined #dri-devel
<karolherbst>
uhh... some undef mess
kts has quit [Quit: Leaving]
pcercuei has joined #dri-devel
<marex>
daniels: danvet: hi, regarding panel-simple, is it OK to pick both the panel simple yaml DT bindings and new panel description in panel-simple.c via drm-misc-next ?
<marex>
sravn: ^
<marex>
tzimmermann: ^
<javierm>
tzimmermann: wonder if we should propose a todo.rst entry to convert all drivers that are using simple-kms...
pallavim has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
yuq825 has left #dri-devel [#dri-devel]
Jeremy_Rand_Talos_ has joined #dri-devel
<javierm>
tzimmermann: I guess others may disagree that doesn't add that much value and it's better to instead focusing on improving the atomic mode helpers and make them easier to be shared among drivers
<danvet>
marex, I am honestly not on top of how to handle dt stuff
<danvet>
iirc the process is that you need an ack from dt folks, and then merge through the subsystem tree
<danvet>
robher, ^^ can clarify if I got this wrong
<marex>
danvet: there is ACK from Rob already
<javierm>
danvet, marex: that's my understanding as well and how I did in the past
<danvet>
marex, so I /think/ the answer is you can push it all
<javierm>
marex: yeah, I would just push it since you already got an ack
<robher>
marex: Yes
<marex>
ok, will do, thanks
<tzimmermann>
javierm, most of the simplekms uses are in drivers that are maintained by noralf. he might not like it ;)
<javierm>
tzimmermann: right
pallavim has joined #dri-devel
ambasta[m] has joined #dri-devel
Andy[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
colemickens 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
Guest1738 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
gagallo7[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
Guest1750 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
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kunal10710[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
kunal_1072002[m] has joined #dri-devel
KunalAgarwal[m][m] has joined #dri-devel
kusma has joined #dri-devel
Labnan[m] has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
masush5[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
michael5050[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
mripard has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
eyearesee has joined #dri-devel
nielsdg has joined #dri-devel
nyorain[m] has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
onox[m] has joined #dri-devel
pac85[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
r[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
robertfoss[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
sjfricke[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
knr has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
underpantsgnome[m] has joined #dri-devel
tleydxdy has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
Soroush has joined #dri-devel
unrelentingtech has joined #dri-devel
viciouss[m] has joined #dri-devel
MatrixTravelerbot[m]1 has joined #dri-devel
Weiss-Fder[m] has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
pmoreau is now known as Guest1760
<javierm>
tzimmermann: did you get an answer about the need for calling drm_atomic_add_affected_planes() in drm_crtc_helper_funcs .atomic_check ?
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<tzimmermann>
javierm, what exactly do you mean?
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: that some drivers call it in their .atomic_check handler and you questioned that the other day and noticed that you are not doing in udl_crtc_helper_atomic_check()
<javierm>
so wondered if you got to the bottom of that
fahien has joined #dri-devel
Eschik has joined #dri-devel
srslypascal has joined #dri-devel
<tzimmermann>
in the end, i didnt need the functionality. so i removed the call. otherwise, my solution was to override the .atomic_check callback and unconditionally add planes before calling drm_atomic_helper_check()
<javierm>
tzimmermann: I see
<javierm>
tzimmermann: I guess there are many drivers that also don't need that functionality but are just calling it due copy&paste from other drivers
<tzimmermann>
i don't know how many drivers use it
<javierm>
tzimmermann: for instance, simpledrm. Or do you need it there?
<tzimmermann>
i mindlessly copied this code from the simplekms helpers
<tzimmermann>
it's not necessary AFAICT and i'll remove it at some point
<javierm>
tzimmermann: yes, same for me in the ssd130x driver...
<tzimmermann>
haha :)
<tzimmermann>
adding a plane to the atomic state without later running the plane's atomic_check appears broken anyway
<javierm>
tzimmermann: indeed, maybe the check could be done in drm_atomic_add_affected_planes() itself and return an errno ?
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
<tzimmermann>
we legitimatelly call it from other helpers. adding atomic_check there would mess up the logic even more
<zmike>
mareko: did you have further comments on my glthread MR?
<tzimmermann>
javierm, it was added in commit 6dcf0de7ef10244b17442f47956a1d9fabe2abe1
sdutt has joined #dri-devel
<tzimmermann>
update didn't get called. but there's little explaination, why not
<tzimmermann>
and there's no comment on why non-simplekms drivers aren't affected by the bug
kts has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
bmodem1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
bluepqnuin is now known as bluepenquin
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
<marex>
btw if anyone needs their panel-simple stuff reviewed and possibly applies, let me know ;-)
Duke`` has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
swalker__ is now known as sarahwalker
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
tzimmermann has quit [Quit: Leaving]
<emersion>
how does one usually land a patch with both DRM core and driver pieces?
<emersion>
just merge everything in the driver tree? or merge in drm-misc-next and backmerge in the driver tree or something?
<emersion>
(cc danvet)
<danvet>
driver tree?
<emersion>
amd for instance
<danvet>
ah drm driver tree
<danvet>
simplest is to get acks from maintainers for merging it all through one tree (drm-misc usually, but could also be the driver tree when one driver is most involved)
<danvet>
not so simple is asking drm-misc maintainers to set up a topic branch which gets pulled into all trees
<danvet>
generally that's overkill
<emersion>
ah, so merge the amd pieces in drm-misc-next?
<danvet>
so just ask agd5f for an ack or merge all the patches for, depending what he prefers
<emersion>
i'll re-spin the series one more time with that thread addressed, but apart from that doc change it should be good to merge
<emersion>
danvet: ah, thanks
frankbinns has joined #dri-devel
fahien has quit [Remote host closed the connection]
fahien has joined #dri-devel
iive has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
robert_mader has quit [Quit: Leaving.]
LexSfX has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
robert_mader has joined #dri-devel
robert_mader has quit []
pallavim has quit [Ping timeout: 480 seconds]
<zmike>
mareko: another idea I've been considering: how reasonable do you think it would be to add a sort of "batch readahead" utility to tc such that a driver could call something like tc_readahead(ctx, bool (*callback)(...), void *data) and gather info about pending calls?
<zmike>
this would specifically be useful for tilers
fxkamd has quit []
sarahwalker has quit [Remote host closed the connection]
Guest1738 is now known as DrNick
JohnnyonFlame has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<mareko>
what kind of information do you expect to get from it?
kem has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
Jeremy_Rand_Talos__ has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<agd5f>
emersion, ack to merge via drm-misc
<emersion>
agd5f: excellent
<zmike>
mareko: I'm imagining it could be used at set_framebuffer_state to check for attachment usage, e.g., determine in advance whether all attachments will be written to, find resolve attachments, that sort of thing
kem has joined #dri-devel
<Ristovski>
zmike: I'd just like to say that I appreciate your insane optimization work, keep it up
<zmike>
🙏
tursulin has quit [Ping timeout: 480 seconds]
<mattst88>
++
pochu has quit [Ping timeout: 480 seconds]
<mattst88>
it's incredible to see the progress we've made since I started in 2012 and we had like 8 intel engineers and about 3 other professionals working on Mesa :)
LexSfX has joined #dri-devel
<karolherbst>
yeah :)
<DavidHeidelberg[m]>
jekstrand: Hey, I noticed that radv-raven-traces:amd64 failed for you once in "vulkan/wsi: Refactors to pull buffer blit decisions into common code". Have you fixed the code or has the job just flaked?
* karolherbst
might kick of a real CTS run for CL on radeonsi
<daniels>
mattst88: srsly
<mattst88>
someone should write a blog post or give an XDC talk about this :)
<karolherbst>
mattst88: could be part of the last talk
<karolherbst>
I think I've done all the prep work to be ready for XDC :)
gawin has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
<bl4ckb0ne>
as you can see the khrplatform file got changed quite a bit, the KHRONOS_APICALL setup seems pretty old, cant even track it on the EGL-Registry git repo
<bl4ckb0ne>
dates from svn
<emersion>
bl4ckb0ne: what do you mean by "the script in bin"?
<emersion>
there's api/Makefile
<bl4ckb0ne>
the script bin/khronos-update.py to fetch all headers
<emersion>
ah
MajorBiscuit has quit [Ping timeout: 480 seconds]
<karolherbst>
okay.. I think our nextafter impl is broken for subnormals and that's what radeonsi returns... mhh
<jekstrand>
DavidHeidelberg[m]: There was a double-free in the X11 WSI code. I fixed it and re-submitted.
<DavidHeidelberg[m]>
jekstrand: nice, great to hear it was not a flake, but "useful failure" :D
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
<jekstrand>
DavidHeidelberg[m]: IDK if it was useful for me in this case. Zink also totally exploded and that's what I used to debug the issue. But it did seem to point something out, yes.
<DavidHeidelberg[m]>
jekstrand: I seen also zink. But since it's freshly deployed, I'm looking for any flakes or issues with the job. For that case, I'm happy it didn't crashed by accident.
kts has quit [Quit: Leaving]
<bl4ckb0ne>
i think its because we have `gnu_symbol_visibility : 'hidden'` everywhere
<bl4ckb0ne>
but i dont get why gl exports just fine
<alyssa>
I don't remember what that MR is stalled on
<alyssa>
but it's about perf
<karolherbst>
me neither
<alyssa>
you don't need it for correctness
<alyssa>
and if you do, you have some other bug somewhere else.
<karolherbst>
well.. I do now
<karolherbst>
and that "bug "is inside LLVM
<alyssa>
you have some other bug somewhere else.
<karolherbst>
LLVM optimizes that way, because it's a mul and not fcanonicalize
<alyssa>
that sounds like an LLVM bug then
<karolherbst>
yeah.. but llvm says: use llvm.canonicalize
<karolherbst>
I just need to detect that pattern in nir_to_llvm
<karolherbst>
but I suspect we want to have !9254 to make that all super explicit
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
simon-perretta-img has joined #dri-devel
<karolherbst>
uhh.. how could I check if a nir source is a const again?
<zmike>
nir_src_is_const?
<karolherbst>
ahh thanks. I always grep for the wrong things
<zmike>
too many nir functions
mvlad has quit [Remote host closed the connection]
<jekstrand>
DavidHeidelberg[m]: :D
<karolherbst>
uhm.. do we also have the same for alu sources?
<zmike>
pass src.src?
<karolherbst>
ahh yeah... I was just thinking of that as well..
alyssa has left #dri-devel [#dri-devel]
<DrNick>
is there a fork of Mesa somewhere that reads $GAMESCOPE_LIMITER_FILE ?
khfeng_ has joined #dri-devel
mhenning has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
<pinchartl>
marex: I'm afraid I'm sending a bit of work your way for the LCDIF driver :-)
frankbinns has quit [Remote host closed the connection]
<karolherbst>
okay.. another try
gouchi has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
<karolherbst>
okay.. I think this is it.. going for the full run now :)
<karolherbst>
I'll report back in like... 10 hours or so
ngcortes has quit [Ping timeout: 480 seconds]
<cwabbott>
karolherbst: fcanonicalize is supposed to be identical to fmul with 1.0, so if it's optimizing it out it's either (a) an llvm bug (which is pretty unlikely) or (b) you're passing too aggresive fast-math flags for opencl (more likely)
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst>
cwabbott: I don't pass any flags
<cwabbott>
then track down where in llvm it's changing
<karolherbst>
also it's not an llvm bug, because it states to use canonicalize
<cwabbott>
it's a bug
<cwabbott>
no, it most definitely does not
<cwabbott>
maybe for performance
<karolherbst>
some LLVM dev told me, that LLVM is right to optimize that mul away
<cwabbott>
uhh, I feel like I'm missing context because that's wrong
<cwabbott>
or you misunderstood them
srslypascal is now known as Guest1799
<karolherbst>
nope
srslypascal has joined #dri-devel
<karolherbst>
there isn't really much to missunderstand
<cwabbott>
they're literally defined in the llvm manual as identical
<karolherbst>
so in nir we insert fmul a 1.0 to force flushing denorms
<cwabbott>
find where it eliminates the fmul and raise a bug/PR
<karolherbst>
"This function should always be implementable as multiplication by 1.0, provided that the compiler does not constant fold the operation."
<karolherbst>
from the docs it sounds like that llvm.canonicalize is special
<cwabbott>
listen, I worked on this for a while for amdgpu and I 100% can guarantee that if you pass the right flags and do the right incantations then denorms *have* to be respected (or not respected)
<cwabbott>
*(or flushed)
<karolherbst>
sure, but radeonsi is passing the flags, and they seem correct
<cwabbott>
pattern-matching mul by 1.0 and turning it into fcanonicalize is not correct, it's just masking a bug elsewhere
<cwabbott>
what happens if llvm optimizes something to 1.0 itself?
<karolherbst>
I don't use the fp in float operations
Guest1799 has quit [Ping timeout: 480 seconds]
<karolherbst>
that's the problem
<cwabbott>
?
<karolherbst>
the fmul a 1.0 is the only fp op
gawin has joined #dri-devel
<cwabbott>
you mean, it's the only floating-point operation in the shader?
<karolherbst>
more or less, yes
<cwabbott>
ok, then you need to track down which llvm pass is changing it
<cwabbott>
usually that involves dumping the text and then compiling it with llc, although I haven't done it in a while
<cwabbott>
I can assure you there is no "eliminate fmul 1.0 a unconditionally" optimization, it is more subtle than that and you are probably messing something else up
<cwabbott>
and anyway, the point I was trying to make with "what happens if llvm optimizes something to 1.0 itself?" is not about this particular shader
<karolherbst>
yeah.. I get that, but the flags to llvm seem to be correct and I didn't mess with them anyway
<karolherbst>
it's all radeonsi doing
<cwabbott>
it's that it's not Correct (tm) and in compilers being Correct (tm) is the only way to stay sane
<karolherbst>
sure
<karolherbst>
anyway.. I posted what the AMD_DEBUG thing starts printing with the llvm stuff above and those seem to be correct at leat from my perspective
<karolherbst>
maybe it's missing a tiny bit? dunno
ngcortes has joined #dri-devel
<cwabbott>
again, copy the entire shader AMD_DEBUG prints out into a file and compile it with llc from your llvm build, use the llc flags to dump out what happens between each pass, find out which pass does the problematic thing, find out why it's doing it
<cwabbott>
I guarantee you it's a problem with *something* you're doing if the shader really is that simple
macromorgan has quit [Read error: Connection reset by peer]
<karolherbst>
again, I am not doing anything here
<cwabbott>
be methodical about tracking down what's going on
<karolherbst>
if this is a bug, then radeonsi is hitting it already today
<cwabbott>
yes, sure
<cwabbott>
then fix the bug!
<karolherbst>
though for GL it might just not matter
<cwabbott>
yes, for GL it won't matter
<cwabbott>
only VK with shader_float_controls or CL
<karolherbst>
anyway.. this has to wait until after XDC.. but I can see that llvm might be confused by the sorounding bitcasts or whatever
<Kayden>
mareko: I don't understand why UNSYNCHRONIZED or PERSISTENT are removing PIPE_MAP_DISCARD_RANGE
<Kayden>
mareko: in my mind, DISCARD_RANGE just means "I don't care about the contents of the destination memory" which also implies "I will not read the destination memory"
<Kayden>
but there's a difference between e.g. MapBufferRange with WRITE that may do -partial- writes of the data, and e.g. BufferSubData which is definitely going to write the entire specified range so the contents no longer matter
<marex>
pinchartl: is that some HW race ?
<pinchartl>
no, it's a software issue only
<pinchartl>
I *think* the issue comes from the fact that the CRTC is enabled without a plane
<pinchartl>
but I haven't double-checked that
<pinchartl>
in any case, the format and stride programmed in .atomic_enable() are not the right values, the next .atomic_update() for the plane has an fb with a different format and stride
<pinchartl>
so the format and stride need to be programmed in .atomic_update() (or possible .atomic_flush())
<pinchartl>
*possibly
gouchi has quit [Remote host closed the connection]
gawin has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
danvet has quit [Ping timeout: 480 seconds]
<marex>
pinchartl: ah ... both of those changes were required as part of the intial driver review I think
aravind has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
<pinchartl>
marex: it seems that the offending structure was copied from the mxsfb driver
<marex>
pinchartl: the whole lcdif was originally just a couple of tweaks to mxsfb really
<marex>
pinchartl: I am still convinced the lcdifv3 is really mxsfb lcdif behind the scenes
<marex>
pinchartl: it just seems like nxp is vehemently denying it
robertfoss has quit [Quit: WeeChat 2.6]
YuGiOhJCJ has joined #dri-devel
elongbug has quit [Read error: Connection reset by peer]