<Lynne>
I think I get it, the bitstream size align may push the size beyond what we've allocated
<Lynne>
after alignment
<airlied>
yup
<Lynne>
tried aligning vp->slice_size, which is the unaligned value, but that didn't work
<airlied>
my hack also cleans things up on anv
<airlied>
with my anv patch
<Lynne>
nope, your hack didn't fix the gpu crash on radv
* Lynne
wants a separate coreboot machine to avoid staring at firmware logos
<airlied>
ah getting a VM fault
<airlied>
I'm guessing then something is undersized in some case then
<airlied>
and the bitstream reader is going off the end of allocated memory
danvet has joined #dri-devel
Duke`` has joined #dri-devel
bgs has joined #dri-devel
Leopold___ has joined #dri-devel
itoral has joined #dri-devel
thellstrom has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
bgs has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
itoral_ has joined #dri-devel
<Lynne>
vlVaSyncSurface has started segfaulting for me for about a week or two now, I'll take this as a sign to finish my vulkan work instead
itoral has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
alarumbe has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
kts has quit [Quit: Leaving]
libv_ has joined #dri-devel
kts has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fab has quit [Quit: fab]
frieder has joined #dri-devel
agd5f_ has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
flibitijibibo has quit [Read error: Connection reset by peer]
ernstp____ has quit [Read error: Network is unreachable]
arnd has quit [Read error: Network is unreachable]
jbarnes has quit [Read error: No route to host]
ernstp____ has joined #dri-devel
arnd has joined #dri-devel
jbarnes has joined #dri-devel
dviola has quit [Remote host closed the connection]
flibitijibibo has joined #dri-devel
zaratustra has quit [Remote host closed the connection]
dviola has joined #dri-devel
zaratustra has joined #dri-devel
fab has quit []
<jani>
tzimmermann: many thanks!
pochu has joined #dri-devel
fab has joined #dri-devel
tursulin has joined #dri-devel
a-865 has quit [Ping timeout: 480 seconds]
clever has quit [Ping timeout: 480 seconds]
clever has joined #dri-devel
fab has quit []
dviola has left #dri-devel [#dri-devel]
fab has joined #dri-devel
dviola has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
kts has quit [Quit: Leaving]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
a-865 has joined #dri-devel
frankbinns1 has joined #dri-devel
Sachiel has quit [Ping timeout: 480 seconds]
fab has quit []
fab has joined #dri-devel
agd5f has joined #dri-devel
<MrCooper>
tzimmermann: did something go wrong with the drm-misc-next pull request? It seems to touch files all over the tree, PR e-mail is almost 1 MB
frankbinns has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
vliaskov has joined #dri-devel
Sachiel has joined #dri-devel
<javierm>
MrCooper: maybe due all the legacy dri1 drivers removal?
<MrCooper>
don't think so
MajorBiscuit has joined #dri-devel
<MrCooper>
all over the tree as in outside of the usual DRM paths
<MrCooper>
e.g. net/
mvlad has joined #dri-devel
hashar has joined #dri-devel
lynxeye has joined #dri-devel
frankbinns2 has joined #dri-devel
frankbinns1 has quit [Remote host closed the connection]
elongbug has joined #dri-devel
jkrzyszt has joined #dri-devel
<jannau>
MrCooper: 6f84981772535 merges drm/drm-next based on v6.2-rc2 while drm-misc-fixes was still on v6.1-rc6
<jannau>
I guess the diffstat is from drm-misc-next-2023-01-19 to drm-misc-next-2023-01-24 which includes the v6.1-rc6 to v6.2-rc2 changes
<javierm>
jannau: yeah, but the diffstat of commit b8f55f24bc82 ("Merge tag 'drm-misc-next-2023-01-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-next") only shows change in drivers/drm/
MajorBiscuit has quit [Ping timeout: 480 seconds]
<javierm>
MrCooper: ^
<MrCooper>
so the PR e-mail is just misleading?
djbw has quit [Read error: Connection reset by peer]
<jannau>
it it is kind of useless, drm-misc-next-X..drm-misc-next-Y ^drm-next-Z (with drm-next-Z merged between drm-misc-next-X and drm-misc-next-Y) would be much more useful
<javierm>
one way to avoid that would be to back merge whatever tag is based drm-next before sending the drm-misc-next PR
<javierm>
but unsure if that would be more useful since git merge would do the right thing anyways
<MrCooper>
that was over half a year ago, and sparked a similar discussion back then; I'd say avoiding the confusion would be worth it
sgruszka has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
thellstrom has joined #dri-devel
ice9 has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
frankbinns1 has joined #dri-devel
frankbinns2 has quit [Ping timeout: 480 seconds]
<frieder>
Are there any DRM bridge driver maintainers around?
<emersion>
hm, apparently this is a more general issue
ahajda has joined #dri-devel
frankbinns1 has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
phasta has joined #dri-devel
thellstrom1 has joined #dri-devel
Cyrinux has quit []
Cyrinux has joined #dri-devel
thellstrom1 has quit []
thellstrom has quit [Ping timeout: 480 seconds]
Cyrinux has quit []
Cyrinux has joined #dri-devel
frankbinns has quit []
frankbinns has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
Yeah we got a bug report about such an issue relatively soon after changing KWin to set max bpc to 16. I changed it to use max bpc = buffer bpc (so 10 in most cases), haven't had any complaints about that yet
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #dri-devel
<MrCooper>
zamundaaa: there's no direct connection between those two things
<MrCooper>
the final output of the colour pipeline of current GPUs has at least 12 bpc AFAIK, regardless of the framebuffer format
<zamundaaa[m]>
This is about port bandwidth limits though, not GPU bandwidth
<MrCooper>
yeah, so what kwin does will artificially cap the colour accuracy on the link in some cases
jkrzyszt has joined #dri-devel
<emersion>
MrCooper: is there any point in 16bps on the link, if the source buffer is 8bpc?
<emersion>
bpc*
<MrCooper>
it's like asking "is there a point in having apples, when there are oranges?" ;)
<emersion>
hm, i'm not following... i know these are unrelated, but it's a pipeline
<MrCooper>
bpc at the end of the pipeline has nothing to do with bpc of the source buffer
<emersion>
if you send bad quality data into the pipe, it's no big deal if the pipe is not high quality either?
<MrCooper>
even 8 bpp pseudocolour could result in 16 bpc at the end of the pipeline
<emersion>
a bit like: my network adapter is 100Mbps, no need for a CAT6 Ethernet cable
<emersion>
right, but the pipeline can't fix missing information in the source
<MrCooper>
it can lose information though
<emersion>
so your point is: if source buffer is 8bpc, and the link is 8bpc, then there can be lost info?
<MrCooper>
it can result in different input values resulting in the same output values, depending on the transformations in between
<zamundaaa[m]>
<MrCooper> "yeah, so what kwin does will..." <- I mean, yes, but there's not really anything better that can be done when compositors don't get any information about the restrictions on connectors
<MrCooper>
zamundaaa: it's a driver issue, needs to be addressed there
<emersion>
this seems very theoretical to me
<daniels>
right, but in the absence of transformations it doesn't help; there is a benefit in choosing lower bpc if it lets you choose a lower link rate, because then you can run your clocks slower, or use fewer lanes which might free up more for e.g. USB
<emersion>
yes, it's a driver issue, but my users an angry and the driver issue is hard to fix
<emersion>
are*
<MrCooper>
daniels: the driver is supposed to lower bpc automatically as needed
<emersion>
yes, but no driver does this today, because it's Difficult
<emersion>
for DP-MST
<MrCooper>
the property is "max bpc", not "effective bpc"
<daniels>
but 'I can lower my clock rate' or 'I can free up some lanes for less bad USB' aren't 'needed', they're just nice-to-haves
<emersion>
i think i'll go with the same fix as kwin for now
aravind has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
daniels: if the output doesn't work without it, it's absolutely needed and not just nice to have
<emersion>
4k@30Hz is not "doesn't work", but not too far :P
<daniels>
zamundaaa[m]: yes
<emersion>
what daniels is saying is that even if 16bpc or 10bpc works, there might be use-cases where it's better to pick a lower one
<emersion>
for power savings, for instance
jdavies has joined #dri-devel
<emersion>
afaiu
jdavies is now known as Guest2396
<zamundaaa[m]>
That makes sense
<daniels>
yeah, or because you're doing alt-mode over type-C, and if you don't use all the lanes then you can get more USB bandwidth
<emersion>
right
<zamundaaa[m]>
So ideally compositors should also read the EDID and check what bit depth the display actually does, and limit it to that. Or does the kernel already do that?
<emersion>
i'm not sure that would help
jdavies_ has joined #dri-devel
<emersion>
for me the tl;dr is that compositors really need a knob to select between quality and power savings/room for other usage
<emersion>
so it sounds reasonable to me to tie max bpc to "is high bit depth on or off"
<MrCooper>
zamundaaa: it's not that simple either, due to things like temporal dithering or DSC
Guest2396 has quit [Ping timeout: 480 seconds]
bluetail3 has joined #dri-devel
libv_ is now known as libv
bluetail has quit [Ping timeout: 480 seconds]
bluetail3 has quit [Ping timeout: 480 seconds]
bluetail has joined #dri-devel
Cyrinux has quit [Remote host closed the connection]
bluetail0 has joined #dri-devel
Company has joined #dri-devel
bluetail has quit [Ping timeout: 480 seconds]
FireBurn has quit [Ping timeout: 480 seconds]
<Ristovski>
It is possible to measure the effective input-to-change latency of a game for example, by mounting a photodiode on the screen and then using some external hw to fire an event (preferably something that changes the brightness of the game, like some menu, instantly) and measuring the time it takes for the brightness to change
<Ristovski>
Would it be also possible if one simply cared about the pure software side?
<Ristovski>
GLX/EGL_EXT_buffer_age is not quite what would be useful. I assume it would require getting the pixel contents and a timestamp of frame (but "higher up" in the chain, since then you are at the mercy of the compositor etc)
<Ristovski>
Imagine a simple app that changes from black to white when you send it any input. In order to detect the change, ideally you would be able to "probe" various points in the pipeline (so from the backbuffer all the way to screen output) and do some naive pixel test on the contents. Is there something like that in mesa/drm that could help?
ice9 has joined #dri-devel
alarumbe has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
itoral_ has quit []
<zamundaaa[m]>
You can definitely measure the output latency of your compositor with an app by using presentation-time, no buffer age or anything like that required
<MrCooper>
emersion zamundaaa: if link bpc is capped to framebuffer bpc, any non-identity gamma transformation cannot be represented on the link directly and losslessly
angerctl has joined #dri-devel
<emersion>
yes, but better have this bug than being capped at 30Hz
<alyssa>
I totally know how to use nir_shader_compiler_options
<alyssa>
don't worry i'm a professional
<zmike>
same
<alyssa>
what's the reference NIR compiler these days
<alyssa>
NAK is rust, ACO is C++, Intel's is nightmare fodder
<alyssa>
who does that leave as the winner
<alyssa>
ir3?
<zmike>
"compiler" = ?
<alyssa>
real hardware
<zmike>
you mean backend
<alyssa>
yes
<alyssa>
i totally know what that word means
<alyssa>
i'm a professsional remember
<zmike>
I do remember
jewins has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
devilhorns has quit []
kts has joined #dri-devel
<cwabbott>
ir3 is weird because it started life making a lot of "my first compiler" mistakes but has been almost completely rewritten by various people over time
<cwabbott>
(no disrespect meant, everyone's gotta start somewhere)
<cwabbott>
there are definitely still a few remnants of the "my first compiler" stage leftover
phasta has joined #dri-devel
<alyssa>
yeah, that's fair
<alyssa>
DAG-based IR?
<cwabbott>
no, it wasn't DAG-based
<alyssa>
* Adreno's comparisons produce a 1 for true and 0 for false, in either 16 or
<alyssa>
* 32-bit registers. We use NIR's 1-bit integers to represent bools, and
<alyssa>
* trust that we will only see and/or/xor on those 1-bit values, so we can
<alyssa>
* safely store NIR i1s in a 32-bit reg while always containing either a 1 or
<alyssa>
.............uh
<alyssa>
inot?
<alyssa>
(-:
Jeremy_Rand_Talos has quit [Remote host closed the connection]
<cwabbott>
that's what it used to do, but inserting inot and then removing it later is harder than just not inserting it
Jeremy_Rand_Talos has joined #dri-devel
<alyssa>
weee
<cwabbott>
it's basically lowering bools to 32-bit in instruction selection, but with a 0/1 representation instead of the default 0/~0
<alyssa>
yeah, I see that
<alyssa>
comment is just for wrong inot, I know because I had that bug in Bifrost
<cwabbott>
oh, right
<alyssa>
(inot is handled correctly by a special case in ir3)
<cwabbott>
anyway, the biggest problem is that in the beginning it tried to map operands in the IR as closely to the assembly as possible
<cwabbott>
sources and destinations had the same ir3_register type, implicit operands weren't inserted at all, and read-modify-write type things reused the same operands as source and destination
agd5f_ has quit [Read error: No route to host]
<alyssa>
oh, interesting, yeah
* alyssa
is guilty of some of the same
<cwabbott>
and as a result there was a wrapper to iterate over "real" sources
<alyssa>
ah, yeah, I remember seeing you clean that up with the SSA stuff
<cwabbott>
also, no support for multiple destinations (ughhhh)
<alyssa>
this is an annoying reminder I never finished either of my SSA RAs, I should probably do that at some point
<eric_engestrom>
the open question was on the license for using GDKX in a CI
neobrain has quit [Remote host closed the connection]
srslypascal has quit [Ping timeout: 480 seconds]
<jekstrand>
eric_engestrom: Neat!
jeeeun8413 has quit []
sgruszka has quit [Ping timeout: 480 seconds]
jeeeun8413 has joined #dri-devel
frieder has quit [Remote host closed the connection]
JohnnyonFlame has quit [Read error: Connection reset by peer]
<enunes>
daniels: DavidHeidelberg[m]: looks like download speed is particularly bad today, it doesn't seem to be something bad on my runner as in a quick test I get my full connection download speed, I wonder if theres anything to do (other than cache proxy)?
mbrost has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<DavidHeidelberg[m]>
enunes: for traces we have the etag checking (so caching traces on NFS), but that's only idea which I have right now
jeeeun8413 has quit []
<enunes>
the jobs on my runners don't use the traces, what is really slow are kernel/rootfs which today are hitting <1MB/s
tursulin has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
Leopold___ has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
FireBurn has joined #dri-devel
ajax_ has joined #dri-devel
ajax has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
<alyssa>
I'm ok with xbox in post-merge but not in pre-merge
<DavidHeidelberg[m]>
robclark: Emma mentioned perffeto enablement
<robclark>
it's possible that has some overhead too.. but also don't really care ;-)
<robclark>
I guess you should have a list of candidate MRs based on which day?
<robclark>
anyways, conservative lrz can be disabled via driconf (and therefore env var) so that would be an easy way to rule out it being related
<anholt>
the commit range didn't cover lrz.
<anholt>
unfortunately the stats thing doesn't decide where the regression happened, so you don't get a list of candidate mrs
<anholt>
you have to click the link and zoom in on the graph and log commit messages where you see the regression happen.
gouchi has joined #dri-devel
<robclark>
ok, then not conservative-lrz.. if the range did include perfetto enable, that seems plausible.. but also not a thing to care about since it is apple vs orange thing
* robclark
amused that android play protect thinks android cts is a sketchy application that it should protect me from
<anholt>
robclark: crashes so many devices, must be some sort of attack!
<robclark>
yup, lol
genpaku has quit [Read error: Connection reset by peer]
<anholt>
ajax_: started checking how hard it would be to run deqp-vk.wsi in ci, to catch that regression. despite being a build that I think should include the tests, just enabling xvfb is not getting tests run from what I can see.
<airlied>
would wsi not need dri3?
<airlied>
i suppose lvp might work in its putimage path
<anholt>
that's what I was thinking
Leopold_ has quit [Ping timeout: 480 seconds]
<daniels>
weston-headless will give you dri3
<daniels>
at least as long as you pass --xwayland
<anholt>
looks like locally I can pass 76, fail 1 with lvp against xwayland with -j 1.
<jekstrand>
Venemo: Done both
<anholt>
weston on ci says command not found. yay for the stupid separate vk container :(
srslypascal has joined #dri-devel
<anholt>
sticking an xvfb-run in locally gets the same results. and xvfb is eating some cpu, so I think the testing may even be valid
<daniels>
anholt: f
<daniels>
anholt: I've got somewhere in my scribbled to-do notes to check if having separate containers actually still makes sense or is just enormous annoyance for marginal gains at this point
<anholt>
daniels: scribble another note in there I came up with today: x11_glx and x11_egl_glx deqp targets are I think exactly the same.
<anholt>
you do need to be using default or x11_*_glx targets in order for vulkan to get x11 wsi. and we probably want to be using default so we can do both wayland and x11 in one build for vk. but then my question is what impact that has on winsys testing for EGL and GL/GLES.
<anholt>
then I imagine trying to trace through the layer cake of GL platform init in deqp, and then well what do you know it's lunchtime already.
kts has quit [Quit: Leaving]
<daniels>
yeah, I've just read through that and wow I cannot tell you how much it's after 8pm
jluthra has quit [Remote host closed the connection]
jluthra has joined #dri-devel
ayaka_ has joined #dri-devel
<zmike>
anyone know how to do a 32bit build with cmake
<zmike>
nevermind I think I remembered
<daniels>
I'm sorry to hear that
<zmike>
me too
<Ristovski>
thanks for ruining my otherwise perfect night by mentioning c*ake
gouchi has quit [Remote host closed the connection]