<tzimmermann>
mripard, morning. i did not r-b all of the patches in your recent vc4 patchset, because of questions. let me know if you want me to take another look
<tzimmermann>
javierm, it was much applauded, but i never heard about it later
<tzimmermann>
has it been merged
<tzimmermann>
javerim, i'm still waiting for vfio devs to ack the one fbdev patch
<tzimmermann>
btw
<javierm>
tzimmermann: hmm, maybe just merge it then? I mean, you gave them a lot of time to answer :)
<tzimmermann>
yeah. i pinged them several times. no answer
<tzimmermann>
the change has no effect on the driver itself. should be find
<tzimmermann>
fine
<javierm>
tzimmermann: agreed
polio has joined #dri-devel
polio has left #dri-devel [#dri-devel]
poliostro has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
Leopold___ has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
ice9 has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<tzimmermann>
i just found out that i can take patchwork's mbox file and pipe it into dim-apply-branch. it appears to do the right thing for each contained patch. amazing!
<tzimmermann>
thanks to whoever implemented this
ice9 has quit [Remote host closed the connection]
ice9 has joined #dri-devel
camus has quit []
<javierm>
tzimmermann: yes, that's what I do. Did you apply one by one before?
<tzimmermann>
i did.
<tzimmermann>
i didn't know that the mbox file would work
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #dri-devel
digetx has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.6]
pallavim__ has joined #dri-devel
<mripard>
it also works from b4
<mripard>
I've been using it for a while, it's great
jkrzyszt has quit [Remote host closed the connection]
dviola has quit [Quit: WeeChat 3.8]
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
kts has quit [Quit: Leaving]
Nyaaori has joined #dri-devel
user__ has quit [Remote host closed the connection]
rasterman has quit [Ping timeout: 480 seconds]
kxkamil has quit []
kxkamil has joined #dri-devel
rasterman has joined #dri-devel
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
Surkow|laptop has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
pallavim__ has quit [Ping timeout: 480 seconds]
devilhorns has quit []
Leopold___ has quit [Remote host closed the connection]
sgruszka has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
<jani>
so I can get the .c compiled to assembler using 'make path/to/file.s', but is there something similar to get the pre-processor output?
<jani>
'make path/to/file.i' does something
<TMM>
Hello! I'm not sure if this is the right channel to ask but I have an annoying yet minor problem with my amdgpu driver. I have two cards installed in my machine, a 6900XT and a 6950XT and I want the 6950XT to be /dev/dri0 because it is where my monitors connect to. In order to do this I had to move the 6950 to pcie slot 7 and the 6900 to pcie slot 1. This all works fine until I turn on the CSM which initializes the gpu in slot1 first and I don't get output on the
<TMM>
card in slot 7. Also, /dev/kfd seems to enumerate the devices in the opposite direction from dri so according to rocm the cards are now swapped
<TMM>
Is there a way to force amdgpu or linux to enumerate the cards the way I'd like them to be enumerated?
<TMM>
Maybe udev? I have no idea and I don't know where to start looking :)
mareko_ has joined #dri-devel
glisse is now known as Guest1257
glisse has joined #dri-devel
fab has quit [Quit: fab]
mareko has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
Guest1257 has quit [Ping timeout: 480 seconds]
dri-logger has quit [Ping timeout: 480 seconds]
dri-logger has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
poliostro has quit [Remote host closed the connection]
jewins has joined #dri-devel
nchery has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
nchery is now known as Guest1258
nchery has joined #dri-devel
kts has joined #dri-devel
mbrost has joined #dri-devel
nchery is now known as Guest1259
nchery has joined #dri-devel
<agd5f>
TMM, you sbios may have an option to pick which GPU the sbios uses for display if that is your concern
Guest1258 has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
Guest1259 has quit [Ping timeout: 480 seconds]
fab has left #dri-devel [#dri-devel]
nchery has quit [Ping timeout: 480 seconds]
yuq825 has left #dri-devel [#dri-devel]
mbrost has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
fab_ has joined #dri-devel
fab_ is now known as Guest1265
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
Company has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
rawoul has quit [Quit: leaving]
djbw has quit [Read error: Connection reset by peer]
Leopold has joined #dri-devel
mbrost has joined #dri-devel
kzd has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
Leopold has quit [Ping timeout: 480 seconds]
<TMM>
agd5f: it does not :(
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
thaytan has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: leaving]
dviola has joined #dri-devel
thaytan has joined #dri-devel
Leopold_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
Leopold_ has quit [Ping timeout: 480 seconds]
ajax has joined #dri-devel
srslypascal has joined #dri-devel
gouchi has joined #dri-devel
djbw has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
mareko_ is now known as mareko
Akari has joined #dri-devel
rawoul has joined #dri-devel
rawoul has quit []
rawoul has joined #dri-devel
Leopold_ has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
*squint*
<alyssa>
can't tell if driver bug or bad piglit
<alyssa>
using a signed `int` output with a _UINT framebuffer
<alyssa>
arb_shader_atomic_counters-semantics
<jenatali>
alyssa: What's the actual problem?
<alyssa>
jenatali: we tell the hardware "i32 input, but u32 output" and so the hw clamps negatives to zero
<jenatali>
Ah
<alyssa>
There's a workaround code path for TGSI (which sets untyped_colour_outputs)
<alyssa>
but I could have sworn this violates the GLSL spec
<mareko>
is passes here
djbw has quit [Read error: Connection reset by peer]
<alyssa>
"If the values written by the fragment shader do not match the format(s) of the corresponding color buffer(s), the result is undefined."
<alyssa>
from the gl46 compat spec
<mareko>
I don't think our hw clamps that
<alyssa>
I can force untyped_color_outputs but that's really silly to do for a piglit that's relying on UB
junaid has joined #dri-devel
junaid_ has joined #dri-devel
bgs has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
pallavim__ has joined #dri-devel
<zmike>
probably just change the piglit
bgs has quit [Remote host closed the connection]
frankbinns has quit [Remote host closed the connection]
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
<italove>
What does it mean when _mesa_get_format_info() doesn't find a format? It doesn't seem to work for NV12 for me. Looking at `formats.csv` I only see two yuv formats, which are mapped to YUYV and UYVY in `formats.h`.
Akari has quit [Quit: segmentation fault (core dumped)]
Duke`` has joined #dri-devel
<alyssa>
italove: for historical reasons MESA formats are separate from PIPE formats
<alyssa>
even though we use the same enum values now
<alyssa>
NV12 textures shouldn't ever come from GL though, only from EGL
<alyssa>
so you probably don't need MESA formats for NV12
<alyssa>
I'm unusre why YUYV is there
<alyssa>
PIPE formats are defined by util/format/
<alyssa>
you'll notice that u_format.csv does have NV12
<alyssa>
as well as NV21, IYUV, etc
pendingchaos has joined #dri-devel
<sravn>
danvet: With all the old drivers gone it looks like we can gc all code that check for drm_core_check_feature(dev, DRIVER_LEGACY)
<sravn>
Or do I miss something obvious where we need it
<italove>
alyssa: maybe it's an issue with the piglit test I'm running then, because it does call _mesa_get_format_info() and leads to crashes
pendingchaos_ has quit [Ping timeout: 480 seconds]
<danvet>
sravn, the plan is to gc in 1.5 years or so
<danvet>
assuming no one screams
jernej has joined #dri-devel
<danvet>
essentially wait until this has all landed in lts
<danvet>
if we start deleting now and need to resurrect a driver, then resurrecting the legacy stuff might be pain
jernej has quit [Read error: Connection reset by peer]
jernej has joined #dri-devel
jernej_ has joined #dri-devel
jernej has quit [Remote host closed the connection]
jernej_ has quit []
<sravn>
danvet: It sorta makes sense. But if reverting a driver removal is painfull, then maybe someone would be sufficiently motivated to update the driver (I am sometimes an optimist)
pendingchaos has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
<sravn>
Anyway, I will bury my itch for now and leave the code in.
jernej has joined #dri-devel
<danvet>
sravn, that sounds very optimistic
<sravn>
Lookign forward to see the comment thread on Phoronix when they pick up the removal
pendingchaos has joined #dri-devel
<danvet>
also note, that this are pure render drivers, display is userspace
<danvet>
which means this _only_ breaks opengl
<danvet>
and you're not going to get a gl1.x driver into mesa these days, that just aint happening
<danvet>
so "just update the driver" is not really a reasonable option
<sravn>
danvet: Ohh, that makes it difficult. I now remember that this was also a topic when I brought up openchrome some time ago - where I wondrered whay it was so much larger than the current kernel driver
junaid_ has quit [Remote host closed the connection]
dviola has quit [Quit: WeeChat 3.7.1]
tursulin has quit [Ping timeout: 480 seconds]
junaid has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
<ajax>
danvet: which hardware is this about? the last userspace with any (strictly) ums 3d support was mesa 7.11, which was 2011
<danvet>
ajax, that kind of hw
<danvet>
unless something really funny happens we should be able to get away with this no problem
junaid has joined #dri-devel
<ajax>
dude. if anyone wants to work on like g400 support and port it to kms, amber will happily take the driver
<ajax>
otherwise: go away
<ajax>
or just run the 11 year old kernel to go with your other >11 year old hardware
<ajax>
i did actually try to build mesa 7.11 with a modern fedora not long ago
<ajax>
it, uh
<ajax>
it didn't
pendingchaos has joined #dri-devel
<ccr>
unsurprising. even a lot newer versions can be a pain to build due to toolchain changes.
<ccr>
or dependency changes
srslypascal has quit [Ping timeout: 480 seconds]
<ccr>
heh. I remember one happy-fun-time regression bisect operation on a software (not mesa tho) that involved juggling autotools versions, some dep library versions, and also the configure parameters themselves had changed.
<Lyude>
danvet: yeah i'm very much not happy about it :\
<Lyude>
if we can figure out an alternative I'm really seriously all for it lol
vliaskov has quit [Ping timeout: 480 seconds]
pendingchaos_ has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
<Lyude>
danvet: I can give another shot at trying to figure out a proper fix. for context: I spent like, over 2-3 weeks trying to figure this out and it got to a point I had to defer to amd because their driver is _really_ difficult to untangle and figure out ._
pendingchaos has quit [Ping timeout: 480 seconds]
<danvet>
ajax, kernel is different about not regressing stuff, and we've had reports and shit even 5+ years after userspace stopped supporting something
<danvet>
or stopped using an old ioctl or whatever
<danvet>
so 10 years is the rule of thumb
<danvet>
and yes I know that mesa routinely gets away with much less
pendingchaos has joined #dri-devel
<Lyude>
danvet: btw responded on the list, I'll try again at figuring out a proper fix for this since I don't know how long it's going to take wayne to figure this out. maybe now that i'm a little burned out I'll figure it out
<Lyude>
*little less
<ajax>
are ci flakes tracked somewhat automatically these days?
pendingchaos_ has quit [Ping timeout: 480 seconds]
pendingchaos_ has joined #dri-devel
danilo has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
dakr has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa>
danvet: how does one get code review
<alyssa>
i remember why i learned to smash my code to marge
<ajax>
review for?
<alyssa>
anything
<alyssa>
Currently have 10 MRs to Mesa that are waiting for review
<alyssa>
mostly panfrost
<alyssa>
mostly from the last 24 hours I admit
<alyssa>
I guess patience is a virtue
<jenatali>
I feel that
<HdkR>
I feel that
<alyssa>
I feel-- wait that's weird nvm
<eric_engestrom>
ajax: grep for FLAKES_CHANNEL in src/**/ci/gitlab-ci.yml to find the IRC channel where the flakes get reported
<ajax>
eric_engestrom: oooh, tyvm
<jenatali>
Unless it's for Windows where we don't have a flakes channel set up...
<ajax>
alyssa: you should take the bait i left on that mipmap generation performance bug
* ajax
looks to see what he can reasonably review
jkrzyszt has quit [Ping timeout: 480 seconds]
<alyssa>
ajax: oooh what bait I don't remember this
<danvet>
alyssa, enjoy w/e, assume wish fairies do the work while you relax, get mad on Monday because they didn't?
<ajax>
i'd believe that for most tilers, tbh, if they only really have one write target per tile job
<alyssa>
"Using the OpenGL meanings of the terms, textures and framebuffers support
<alyssa>
Errr
<alyssa>
See the paragraph starting that
<alyssa>
TL;DR we need to do the write from frag shaders (not compute shaders) to get compression
<alyssa>
which matters more for mipmap sampling perf which is more important than mipmap gen perf
<ajax>
oof
<ajax>
okay hm
<HdkR>
Most hardware would want to do the write from fragment to get compression even
<HdkR>
Quite a new feature that compute image stores get compression
<alyssa>
I think new Apple hw can do it maybe
<HdkR>
ooo
<HdkR>
Nvidia and AMD it is only supported in the last two or three generations as well
<HdkR>
Matters less there because of big BW numbers though
<alyssa>
yeah
<ajax>
i assume there has to be a way to blit an uncompressed resource into an undefined one and get compression at the end, but that's probably a bunch of expensive flush and stall so maybe not worth it
<alyssa>
that sounds, more expensive?
<ajax>
is there not a way to write to multiple levels from fs?
* ajax
spend embarassingly little time on the "writing things in opengl" side of opengl
srslypascal has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
<HdkR>
I wonder if you could bind a framebuffer that overlaps the full mipmap chain and generate it as a single RT
<alyssa>
please no
<HdkR>
Trying to think of something beyond *magic*
<ajax>
the trick is you want to write corresponding pixels in corresponding miplevels from the same shader invocation
<ajax>
because your fs is going to be invoked once per dest pixel
<HdkR>
MRT doesn't save you here sadly
Dr_Who has joined #dri-devel
<ajax>
if you bind a giant image over all the levels then when your coords put you in the smaller levels you have to do exponentially more sampling work
<ajax>
it'd be as if you built the smallest level directly from the largest
<HdkR>
Yea, it's not great
<HdkR>
But would it be faster than back to back FS invocations? :P
<HdkR>
And are the GPU's caches big enough to help out
<eric_engestrom>
DavidHeidelberg[m]: re: gbm without a builtin backend, yeah I think it's reasonable
poliostro has joined #dri-devel
ngcortes has joined #dri-devel
danilo has quit []
dakr has joined #dri-devel
<alyssa>
ERROR - Failure getting dEQP run results: parsing results: Reading from dEQP: timed out waiting for fd to be ready (See "output/c4.r1.caselist.txt")
<CounterPillow>
That's beside the point that mpv would rather not be on this list, as 1. we present at a predictable framerate, 2. oddball video refresh rates make adaptive sync beneficial to us
Haaninjo has joined #dri-devel
<alyssa>
driconf? scalable?
kts has quit [Quit: Leaving]
<HdkR>
Application configs and scalability aren't ever a thing
<HdkR>
It's more likely the list was generated when initial adaptive sync support was added and there wasn't quite enough care to ensure every application handled it fine. A bit of an overreach
<alyssa>
this is so weird
<alyssa>
I can see the tests are running but deqp-runner isn't getting any input?
srslypascal is now known as Guest1282
<HdkR>
stdin says nope today?
srslypascal has joined #dri-devel
Guest1282 has quit [Ping timeout: 480 seconds]
<alyssa>
seemingly
<alyssa>
I uprevved deqp-runner and it seems marginally better
<jenatali>
Urgh, somehow I force-pushed a wrong version of a patch into a MR and didn't notice at some point
<alyssa>
getting some inexplicable crashes, though
<alyssa>
Test case 'dEQP-GLES2.functional.lifetime.attach.deleted_input.texture_framebuffer'.. Pass (Pass)
<alyssa>
stderr: (empty)
<jenatali>
That's... a pass? Not a crash?
<alyssa>
jenatali: same
<alyssa>
deqp-runner was working this more..
<alyssa>
morning
<alyssa>
It's also 10x slower than it was..
<alyssa>
even though I'm seeing appropriately high CPU activity
<alyssa>
oh this is interesting
<alyssa>
sysprof says it's totally bound by disk_cache_evict_lru_item
<alyssa>
ugh. ok. I understand now.
* alyssa
tosses out .cache/mesa_shader_cache
<alyssa>
and it works properly now. miracle ;-;
<alyssa>
getdents64 bound
<alyssa>
apparently that path isn't supposed to happen ;-;
<alyssa>
(the is_two_character_sub_directory path)
<alyssa>
possibly my "uprev mesa" script needs to torch the cache
Leopold___ has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
<HdkR>
alyssa: Bounded by getdents sounds scary. How slow is that SSD? :O
junaid has quit [Remote host closed the connection]
junaid has joined #dri-devel
<HdkR>
alyssa: As a comparison point, my Snapdragon's eMMC peaks out at 20MB/s :|
<HdkR>
No wait, that's a USB 3.0 NVMe drive. wtf
apinheiro has quit [Ping timeout: 480 seconds]
<kisak>
looking at he adaptive sync blacklist from 4 years ago, it looks like it's from the initial implementation push of vrr in foss drivers. The blacklist handwavy needed to unblock the feature rollout without big regressions. There's a good chance other related parts have gotten healthier in 4 years.
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<alyssa>
do I dare to try to set up Anbox or Waydroid
<alyssa>
or, god forbid, FEX
<HdkR>
alyssa: Trying to run closed source games? :P
<alyssa>
idk I can only play STK so many times
<HdkR>
whaaa, no way
<Lynne>
you haven't beaten q3dm17 yet, have you?
<HdkR>
I think more interesting is expanding the pool of games to test
<alyssa>
this reminds me I still need to get my hands on some Wii games
dviola has joined #dri-devel
Akari has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
freemint has quit [Remote host closed the connection]
freemint has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
Leopold___ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
alyssa has quit [Quit: leaving]
ngcortes has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest1291
rasterman has quit [Quit: Gettin' stinky!]
srslypascal has joined #dri-devel
poliostro has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
srslypascal has quit []
Guest1291 has quit [Ping timeout: 480 seconds]
Guest1265 has quit []
srslypascal has joined #dri-devel
jfalempe has quit [Quit: Leaving]
gouchi has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Remote host closed the connection]