ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
sigmaris has quit [Ping timeout: 480 seconds]
<marex>
I figured I might as well try and ask here as a last resort measure
<marex>
I have this MX8M SoC, capable of up to 4-lane DSI, but I want to connect 9 MHz 480x272 DPI panel to it
<marex>
the panel has a LVDS to DPI bridge wired on it already, so I cannot remove that, hence, I am looking for DSI-to-LVDS bridge, which is capable of running the LVDS output end at 9 MHz
<marex>
so far, I found nothing ... TI DSI8x has lower limit of 25 MHz, Toshiba options same thing (both drivers should likely be patched to block those frequencies below 25 MHz), ITE might be an option, Lattice has Crosslink FPGA, but that seems like an overkill
<marex>
any hints ? :)
ngcortes has joined #dri-devel
<marex>
oh, that ITE IT6121 has no public datasheet and very little information available in general
camus has quit []
tursulin has quit [Read error: Connection reset by peer]
Lucretia has quit []
YuGiOhJCJ has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
Lightkey has quit [Ping timeout: 480 seconds]
Lightkey has joined #dri-devel
sdutt has joined #dri-devel
vivek has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
ngcortes has quit [Remote host closed the connection]
adavy_ has quit [Read error: No route to host]
sdutt has joined #dri-devel
Company has quit [Quit: Leaving]
sdutt has quit []
sdutt has joined #dri-devel
sdutt_ has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
nchery_ has joined #dri-devel
vivekk has joined #dri-devel
jcline_ has joined #dri-devel
jcline has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
nchery_ has quit []
vivek has quit [Ping timeout: 480 seconds]
boistordu has joined #dri-devel
boistordu_old has quit [Ping timeout: 480 seconds]
tarceri has quit [Remote host closed the connection]
reinist12 has joined #dri-devel
sigmaris has joined #dri-devel
<airlied>
anholt_: I'm seeing valgrind warnings that my brain can only work out as possible xxhash strict aliasing problems
<airlied>
it's mostly complainging about uninit things that are clearly inited
flto has quit [Read error: Connection reset by peer]
flto has joined #dri-devel
tzimmermann has joined #dri-devel
pnowack has joined #dri-devel
Duke`` has joined #dri-devel
danvet has joined #dri-devel
reinist12 has quit []
itoral has joined #dri-devel
mattrope has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
yoslin has quit [Ping timeout: 480 seconds]
yoslin has joined #dri-devel
tarceri has joined #dri-devel
yoslin has quit [Quit: WeeChat 3.1]
yoslin has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
yoslin has quit []
yoslin has joined #dri-devel
aissen has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Anorelsan has joined #dri-devel
sdutt_ has quit [Remote host closed the connection]
sdutt_ has joined #dri-devel
lemonzest has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
rasterman has joined #dri-devel
<graphitemaster>
Are there prebuilt .so's of Zink mesa for x86_64 anywhere or do I have to build it myself
camus has joined #dri-devel
Hi-Angel has joined #dri-devel
jkrzyszt has joined #dri-devel
<daniels>
idr: I’ve been hotplugging like that for years and it’s always worked fine. would be a bit of a showstopper for a desktop if it didn’t tbh
<evadot>
is there a way to debug driver selection ?
<evadot>
it seems that in FreeBSD we use i965 instead of iris with the 21.1.5 update
<evadot>
I saw nothing obvious in the logs except that prefer-iris is now true by default (which shouldn't affect this)
camus has quit [Read error: Connection reset by peer]
<evadot>
I see that -DPREFER_IRIS is correctly set when we compile loader.c/pci_id_driver_map.c so I'm a little lost here ...
<jadahl>
idr: you're saying you had a backtarce?
cef is now known as Guest2541
cef has joined #dri-devel
Guest2541 has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
<pq>
idr, Wayland may be the common *theme*, but Wayland has so few bits in it and they are so harshly treated that they probably are not at fault. ;-)
<pq>
*harshly beaten up
hch12907 has joined #dri-devel
nirmoy has joined #dri-devel
rsalvaterra_ has joined #dri-devel
sdutt_ has quit [Remote host closed the connection]
<dj-death>
none of the jobs started on the last run
ppascher has joined #dri-devel
<daniels>
dj-death: if I had to guess, I'd say that vulkan-overlay doesn't trip any of the jobs in the source-dep-map, so nothing is scheduled to run, so there is no MR pipeline
alatiera0 is now known as alatiera
<MrCooper>
daniels: the MR is in a bad state, it's not creating MR pipelines anymore
<MrCooper>
I've seen something similar before, it's rare though thankfully
<dj-death>
daniels: previous run did everything but the AMD builders and it failed too
<daniels>
which means something is broken in the job-dependency rules, because it should never create manual jobs for a MR, because it will make everything time out
<MrCooper>
daniels: because it's not an MR pipeline
<daniels>
ooh yeah, I see
<daniels>
that's the ref in the fork
<daniels>
which means no MR pipeline is ever getting created
<MrCooper>
don't know if this MR can be fixed or if a new one needs to be created
<dj-death>
I can create a new one, no problem
<dj-death>
thanks for the tip
<MrCooper>
maybe leave this one open for now though
<MrCooper>
in case daniels wants to investigate
<dj-death>
sure
yoslin_ has joined #dri-devel
yoslin_ has quit []
yoslin has quit [Quit: WeeChat 3.1]
yoslin has joined #dri-devel
yoslin_ has joined #dri-devel
yoslin has quit []
yoslin has joined #dri-devel
yoslin_ has quit []
yoslin has quit [Quit: WeeChat 3.1]
yoslin has joined #dri-devel
yoslin has quit [Quit: WeeChat 3.2]
yoslin has joined #dri-devel
Anorelsan has quit [Quit: Leaving]
yoslin has quit [Quit: WeeChat 3.2]
yoslin has joined #dri-devel
Kayden has quit [Remote host closed the connection]
Kayden has joined #dri-devel
Company has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
iive has joined #dri-devel
yoslin has quit [Quit: WeeChat 3.2]
yoslin has joined #dri-devel
vivijim has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
ppascher has joined #dri-devel
itoral has quit [Remote host closed the connection]
xexaxo has quit [Ping timeout: 480 seconds]
xexaxo has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
Peste_Bubonica has joined #dri-devel
aissen has joined #dri-devel
yoslin has quit [Quit: WeeChat 3.2]
yoslin has joined #dri-devel
yoslin has quit []
lemonzest has quit [Quit: Quitting]
mattrope has joined #dri-devel
yoslin has joined #dri-devel
Hi-Angel has quit [Remote host closed the connection]
sdutt_ has joined #dri-devel
<arnd>
jstultz: I noticed a randconfig failure after your b42000e4b874 ("firmware: qcom_scm: Allow qcom_scm driver to be loadable as a permenent module"):
<arnd>
adreno_gpu.c:(.text+0x1e8): undefined reference to `qcom_scm_is_available'
<arnd>
the problem is that now you can have scm as a loadable module when adreno is built-in but ARCH_QCOM is disabled
<arnd>
any idea? The best I could think of would be to turn the select into
<arnd>
depends on QCOM_SCM || (QCOM_SCM=n && ARCH_QCOM=n)
LaserEyess_ has joined #dri-devel
LaserEyess has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
sdutt_ has quit []
sdutt has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
ppascher has joined #dri-devel
LaserEyess_ has quit []
LaserEyess has joined #dri-devel
<MrCooper>
pepp: almost 100x speedup for some pbobench cases? 8-O
alyssa has left #dri-devel [#dri-devel]
nchery has joined #dri-devel
Duke`` has joined #dri-devel
sneil has quit [Quit: Leaving]
sneil has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
agx has quit [Read error: Connection reset by peer]
<alyssa>
In a traditional chaitin style allocator, when building an interference graph, you add interference between the destinations of each instruction with everything in the live set.
<alyssa>
For a pure register-register move from an SSA value to an SSA value, can the interference between the destination and the live source be skipped?
<alyssa>
It seems so - the "general" definition of interference is having different values at some point in the program
Guest2600 has quit [Ping timeout: 480 seconds]
<alyssa>
A register-register move has the same value on both sides immediately after the instruction, and the SSA condition means that holds throughout the value's lifetimes.
<alyssa>
Is that.. er, is that QED?
<bl4ckb0ne>
is there a list somewhere that matches dri drivers to HW?
<bl4ckb0ne>
got it
<bl4ckb0ne>
so polaris10 is directly gallium, no dri driver
<alyssa>
dschuermann: I recall seeing the above discussion in one of the RA papers I read a few weeks ago but am still shaky on the correctness
<alyssa>
I guess I can always try proof-by-dEQP
camus has joined #dri-devel
<idr>
jadahl: There's a tiny, 3-line backtrace in the journalctl output.
<emersion>
bluebugs: almost all drivers use gallium nowadays
<emersion>
err
<emersion>
bl4ckb0ne: ^
<bl4ckb0ne>
i cant completely disable dri drivers right?
<idr>
bl4ckb0ne: The Gallium drivers use DRI.
<idr>
All of the nomenclature has gotten muddied up over the years.
<bl4ckb0ne>
i activated only r100 and r200 just in case
<dj-death>
ah no, it started
<idr>
dcbaker did a fantastic job on meson... just enable the stuff that you want, and the right dependencies will get built.
<idr>
bl4ckb0ne: ^
<bl4ckb0ne>
yeah so far i avoided a lot of wasted build time
<bl4ckb0ne>
just a bit lost
frieder has quit [Remote host closed the connection]
Peste_Bubonica has quit [Remote host closed the connection]
Peste_Bubonica has joined #dri-devel
graphitemaster has quit [Ping timeout: 480 seconds]
<jadahl>
idr: didn't coredumpctl catch it?
graphitemaster has joined #dri-devel
<dschuermann>
alyssa: why would you have such copies in the first place?
Simonx22 has quit [Ping timeout: 480 seconds]
<alyssa>
dschuermann: currently don't have p_create_vector modeled in the IR, and instead lower to a sequence of moves with offsets.
<idr>
jadahl: Yes... and there is a bit more stack there.
<dschuermann>
then you try to alias vectors with their values in the same register?
<alyssa>
dschuermann: Yes. It's not good, I know.
<alyssa>
Modeling p_create_vector properly is on the todo list (and will clean up liveness analysis) but when I tried last it had some regressions I couldn't solve and then I moved onto other things
<dschuermann>
I'd vote against graph coloring for ssa RA
<dschuermann>
because splitting live ranges becomes awefully complicated
<alyssa>
Since it looks like I'll be doing Bifrost+1 as an extra backend for the existing Bifrost compiler I have more motivation to actually get BIfrost right though.
<alyssa>
It's not SSA RA. At least not yet ... I do plan to do ssa RA for apple as a warm-up
<dschuermann>
ah ok
<alyssa>
(Currently I do ssa ra for the SSA parts but lower phi nodes to nir_register and just pin the high registers to nir_register. Yes, this means every shader gets the worst possible thread count and no spilling and ...)
<dschuermann>
in normal RA you can coalesce copies anyway, no?
<alyssa>
Ah, er, maybe?
<alyssa>
bifrost's RA is jank
<alyssa>
but it works and er
<alyssa>
Getting some regressions from the patch. So I guess my proof is wrong :')
<alyssa>
dschuermann: I suppose you're going to tell me to grow up and do p_create_vector properly then? ;)
<dschuermann>
heh, no. I SSA also has issues with it
<dschuermann>
because you always create copies if the value survives
<dschuermann>
cwabbott probably made best progress on that front
<alyssa>
Mmf.
<alyssa>
IIRC I was struggling with the fact it means effective parallel copies
<alyssa>
if I have `0 = p_create_vector 1, 2, 3, 4` and then that gets allocated as `R0 = p_create_vector R1, R0, R3, R2` ... you need swaps post-RA now?
<dschuermann>
yes
<cwabbott>
typically non-SSA allocators split p_create_vector into a series of moves, then try to coalesce them
<cwabbott>
and don't have that problem
<cwabbott>
but then you need competent register coalescing and keeping tracking of liveness of subregisters
<dschuermann>
how do they handle interference between src and dst?
<dschuermann>
ok
<dschuermann>
so same issues but viewed differently
<dschuermann>
I think that holds for that whole topic
<cwabbott>
like alyssa said, if a is live during b's definition but it's a copy then they don't interfere
<cwabbott>
it's kinda similar to cssa coalescing
<cwabbott>
and the value optimization there
<mriesch>
ezequielg: may i bug you for a minute? :-)
<dschuermann>
no, but you can get badly scattered registers, e. g. if that vector is consumed by a large load which then doesn't have space
xexaxo has quit [Ping timeout: 480 seconds]
<cwabbott>
right... and with graph-coloring RA, as per usual, then you just have to swallow the loss and spill
* alyssa
gulps
<cwabbott>
there are some fancy algorithms that try to delay coalescing to get around that
<cwabbott>
ofc it's not as, err, smooth as SSA based allocation, though yeah that has its own problems
<cwabbott>
nothing's perfect *shrug*
* dschuermann
will try graph based register recoloring, but can't promise anything before xdc
<jstultz>
arnd: I'd guess DRM_MSM needs a depends on QCOM_SCM || QCOM_SCM=n ? let me try to reproduce the config and test that
thellstrom has quit [Quit: thellstrom]
xexaxo has joined #dri-devel
<anholt_>
airlied: I thought we smashed the #defines on xxhash to avoid its strict aliasing problems
<anholt_>
I only have a vague recollection here.
lemonzest has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
hch12907 has quit [Remote host closed the connection]
hch12907 has joined #dri-devel
<jstultz>
arnd: or alternatively maybe QCOM_SCM should add depends on ARCH_QOCM
<jstultz>
arnd: i'll tinker a bit and send a patch out for discussion. thanks for the heads up
Kayden has quit [Read error: Connection reset by peer]
Kayden has joined #dri-devel
ngcortes has joined #dri-devel
macromorgan has quit [Remote host closed the connection]
<arnd>
jstultz: this is what I'm building with at the moment, but it's too early to say if that's sufficient, kernel builds on current linux-next seem a lot slower than they used to
<zackr>
tzimmermann: were you planning to send a drm-misc-next-fixes pull request anytime soon? if not can i ask for one? i have two important fixes in it that would be great to get upstreamed as soon as possible
sdutt_ has joined #dri-devel
sdutt has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
<sravn>
dianders: I would add a Fies: to "drm/bridge: ti-sn65dsi86: Add some 100 us delays" and then we could apply them all to drm-misc-fixes. What do you think?
<sravn>
dianders: s/Fies:/Fixes:/
<tzimmermann>
zackr, drm-misc-next-fixes is closed until -rc6
<tzimmermann>
zackr, i can try to merge it into drm-misc-fixes, so that your patches will be part of next week's PR
<tzimmermann>
the patches would reach upstream later next week
Peste_Bubonica has joined #dri-devel
<bl4ckb0ne>
is there a DRM format that expresses depth?
<zackr>
tzimmermann: eh, i'm sorry. i could have sworn drm-misc-fixes was for the next version, which, i guess, is the case but only after rc6. i can merge the two patches back into drm-next-fixes myself
<tzimmermann>
zackr, you mean drm-misc-fixes?
<tzimmermann>
please don't
<tzimmermann>
if you apply the patches to a separate branch, we have the same change under two different git hashes. it's a problem for people backporting patches into older kernels. (i.e., people like me ;)
xexaxo has quit [Ping timeout: 480 seconds]
<tzimmermann>
i often get requests for backporting patches, only to find the same change has already been backported with a differnt git hash
<tzimmermann>
it's faily annoying
<tzimmermann>
i'll merge drm-misc-next-fixes next week before sending out drm-misc-fixes
<tzimmermann>
if that doesn't work, i'll get back to you
<zackr>
tzimmermann: got ya. yes, that makes sense. i'm not in a hurry, i just wanted to make sure they'll get there before final release
<zackr>
tzimmermann: sounds great
<tzimmermann>
zackr, don't worry about getting the branches wrong
<tzimmermann>
it's an endless struggle
<tzimmermann>
during hand-over times (rc6 and rc1), we usually have issues with patches that got in too late. so there's naturally some friction
<tzimmermann>
just try to keep in mind the diagram i linked to
<zackr>
tzimmermann: well, it's just putting a serious strain on my "everything i do is perfect" mantra that i live by ;) i'm trying to get a better handle on the process in general
<tzimmermann>
lol, ok
<tzimmermann>
but even though i do the sub-maintainer thing here, i still feel like i mess up from time to time.
<tzimmermann>
i don't think you lost a lot of karma on this one :)
tzimmermann has quit [Quit: Leaving]
sdutt_ has quit []
sdutt has joined #dri-devel
xexaxo has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
mattrope has quit [Remote host closed the connection]
sdutt has quit [Remote host closed the connection]
ngcortes has quit [Remote host closed the connection]
ramaling has quit [Remote host closed the connection]
ramaling has joined #dri-devel
sdutt has joined #dri-devel
shankaru has quit [Remote host closed the connection]
Ryback_ has quit [Remote host closed the connection]
mattrope has joined #dri-devel
rsripada has quit [Remote host closed the connection]
mdnavare has quit [Remote host closed the connection]
aswar002 has quit [Remote host closed the connection]
Ryback_ has joined #dri-devel
mdnavare has joined #dri-devel
ngcortes has joined #dri-devel
unerlige has quit [Remote host closed the connection]
Kayden has quit [Remote host closed the connection]
pzanoni has quit [Remote host closed the connection]
nchery has quit [Remote host closed the connection]
pzanoni has joined #dri-devel
shankaru has joined #dri-devel
unerlige has joined #dri-devel
nchery has joined #dri-devel
mbrost has quit [Remote host closed the connection]
vivijim has quit [Remote host closed the connection]
vivijim has joined #dri-devel
mbrost has joined #dri-devel
tursulin has quit [Remote host closed the connection]
rsripada has joined #dri-devel
aswar002 has joined #dri-devel
Kayden has joined #dri-devel
tursulin has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
ngcortes has quit [Remote host closed the connection]
sdutt has quit [Remote host closed the connection]
ramaling has quit [Remote host closed the connection]
aswar002 has quit [Remote host closed the connection]
sdutt has joined #dri-devel
Ryback_ has quit [Remote host closed the connection]
shankaru has quit [Remote host closed the connection]
rsripada has quit [Remote host closed the connection]
mdnavare has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
unerlige has quit [Remote host closed the connection]
Kayden has quit [Remote host closed the connection]
pzanoni has quit [Remote host closed the connection]
nchery has quit [Remote host closed the connection]
pzanoni has joined #dri-devel
vivijim has quit [Remote host closed the connection]
unerlige has joined #dri-devel
nchery has joined #dri-devel
shankaru has joined #dri-devel
tursulin has quit [Remote host closed the connection]
Kayden has joined #dri-devel
mattrope has quit [Remote host closed the connection]
aswar002 has joined #dri-devel
mattrope has joined #dri-devel
rsripada has joined #dri-devel
tursulin has joined #dri-devel
ramaling has joined #dri-devel
Ryback_ has joined #dri-devel
vivijim has joined #dri-devel
mbrost has joined #dri-devel
nirmoy has quit []
rsalvaterra_ has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
letoram has quit []
thellstrom has joined #dri-devel
alyssa has joined #dri-devel
xexaxo has quit [Ping timeout: 480 seconds]
<alyssa>
anholt_: deqp-runner suite support means we can run the KHR-GLES* tests without adding a bunch of overhead on top of deqp?
<anholt_>
yeah
<anholt_>
and the msaa tests
<anholt_>
tomeu: do any of the intel lava boards not have the "whoops, disappeared during the test run" failure mode?
<alyssa>
anholt_: awesome, that's motivation enough for me to review :)
<dianders>
sravn: Sure, that's fine with me. I just didn't add a Fixes on that one because it didn't fix any issues I was aware of, but technically the delays should have always been there.
<dianders>
Do you want me to re-post it?
<jekstrand>
anholt_: How on earth did you manage to write an entire kernel driver in 12 files?
<airlied>
jekstrand: intel_display.c tries to do it in one :-P
<jekstrand>
airlied: :P
<jekstrand>
airlied: Yes, but v3d_gem.c is 962 LOC while i915_gem_execbuffer.c is 3412 LOC. It's downright depressing.
<alyssa>
jekstrand: v3d is a work of art. what's your point?
<jekstrand>
Maybe I can make up for all my +LOC in Mesa with -LOC in i915?
<alyssa>
jekstrand: By the way, I finally diagnosed a really bad mali errata
<alyssa>
will @ you on twitter ;p
<jekstrand>
alyssa: Sounds good. :)
<alyssa>
actually the write up won't really fit on twitter because of char limit, it's that obscure :p
<jekstrand>
i915_gem_execbuffer.c 3412 LOC. All of v3d is 4222 LOC. :-(
<jekstrand>
This is depressing
<Sachiel>
burn it and start anew
<jekstrand>
If only....
<idr>
v3d just hasn't had enough years to grow all those lines of technical debt.
<anholt_>
no, i915 kernel made a lot of bad micro-optimization decisions at the cost of code size.
<anholt_>
I mean, supporting a single gen is part of its small size
<bnieuwenhuizen>
jekstrand: you can always look at amdgpu and get that sense of smug tiny code in i915 back :)
<anholt_>
but there's also "use common code, it's been around for ages now why are you going it alone?"
<imirkin_>
bnieuwenhuizen: is amdgpu a lot of code? or just a lot of #defines?
<emersion>
definitely both
<bl4ckb0ne>
isnt there also a lot of generated code?
<emersion>
i would remove that "just", that said :P
<bnieuwenhuizen>
imirkin_: wc -l in drivers/gpu/drm/amd/amdgpu (which doesn't include all the register defines) is ~237k
<jekstrand>
bnieuwenhuizen: Yeah, amdgpu is a monster...
<bnieuwenhuizen>
that doesn't include code for display :)
<alyssa>
jekstrand: asked and answered.
<jekstrand>
So if those are the only other two drivers in the tree, i915 is... average?
<bnieuwenhuizen>
oh hmm, i915/... is actually 312k lines, more than I expected ...
<emersion>
amdgpu display code is 224k
<bnieuwenhuizen>
then again amd/display is also 300k ...
<emersion>
(excl whitespace and blanks)
<bnieuwenhuizen>
now if only we could remove some of that duplication everywhere
<anholt_>
had a little freedreno farm outage. took the opportunity to do a gitlab-runner upgrade we needed to do, hopefully should be back up now
<sravn>
You guys should learn somethign from the drivers in tiny/. All except one is less than 1000 loc.
<sravn>
dianders: A respin would be nice, then you avoid that I do something stupid.
<sravn>
dianders: The fixes will be drm-misc-fixes material, the driver needs a review first. Quick note on the driver, try to be rid of VIDEOMODE_HELPERS
<pcercuei>
< sravn> You guys should learn somethign from the drivers in tiny/. All except one is less than 1000 loc.
<pcercuei>
and none of them usable by a regular DRM driver
<pcercuei>
which means every single one of them will have to be rewritten at some point
<alyssa>
womp womp
<dianders>
sravn: OK. You want me to spin a v2 w/ just adding "Fixes" right away, or wait for a review of the driver? Actually, I don't need VIDEOMODE_HELPERS, so I can just drop that from the KConfig. I missed removing it when I copied from panel-simple.
<sravn>
pcercuei: Yeah, there is some room for improvements also in the tiny land
<sravn>
dianders: I will review the driver soonish, too late for that for today. Maybe someone else also gives feedback
<sravn>
dianders: So yes, wait
<dianders>
sravn: OK, sounds good. If I don't hear anything by Friday I'll re-spin since I'm on vacation next week.
<dianders>
That'll also give the people with Oscilloscopes in China a chance to double-check my final version, since I made some changes since the last time they tried it.
<anholt_>
alyssa: you can, too, thanks to drm-shim.
<jekstrand>
alyssa: Trying to make a core opt loop?
<alyssa>
anholt_: I guess I could..
<alyssa>
jekstrand: No, I just took the opt_shrink-vectors pass ordering from intel/etna and that hurt a bunch of things in shader-db, so then I checked the tree for all the callers
<alyssa>
nir_to_tgsi and radv_shader call it after cse so don't have the issue
<alyssa>
the shader exhibiting the most help/hurt from this is in t-rex so i guess that's not in upstream shader-db though ...
<alyssa>
before CSE, that's two load_inputs of vary with 3 components
<alyssa>
after CSE that's one load input with 3 components
<alyssa>
but if you shrink vec, the first load_input goes to 2 components
<alyssa>
and then CSE can't help you
<alyssa>
but if you CSE after shrink_vec, you get only a single load
<alyssa>
so "shrink vec first" causes you load to 5 components instead of 3!
<alyssa>
Of course it's also possible something else is wrong in my backend since this should be sorted before lower_io
<jekstrand>
Why is intel_stub_gpu making it try to load i915?
<imirkin_>
alyssa: dunno how your hw works ... on nouveau we do everything per-component first, then CSE, and *then* merge loads
<jekstrand>
imirkin_: With vec4, you typically never want to scalarize. You just can't get it back.
<anholt_>
alyssa: I think most of us don't see that because of lower_io_to_temporaries
<alyssa>
anholt_: Ah, sure
<imirkin_>
jekstrand: agreed
<anholt_>
(and, if you didn't do lower_io_to_temporaries, I think you'd want a load-merging pass like vectorize_io does for other io
yoslin has quit [Quit: WeeChat 3.2]
<imirkin_>
on nv50+, it's scalar, with a handful of "wide" load/store ops
<alyssa>
anholt_: I think that's the underlying cause for me .. I don't call io_to_temps explicitly, which means it falls back to what mesa/st does
yoslin has joined #dri-devel
<alyssa>
what seems to lower everything for vertex/geom but not for fragment
<alyssa>
I'll give `.lower_all_io_to_temps = true,` a try.
<alyssa>
this is a lot of voodoo, i have to say.
mdnavare has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<mdnavare>
When I try it , it tries to import fb from second device (dgfx) to first and the commit with the imported fb fails trying to figure out the issue there
<mdnavare>
Has anyone tried the IGT kms_prime on a system with discrete gfx card?
<mdnavare>
jekstrand: Kayden: danvet: Do you have any clue on what might be happening here?
mlankhorst has quit [Ping timeout: 480 seconds]
<jekstrand>
mdnavare: How does it fail?
<mdnavare>
(kms_prime:2433) igt_kms-CRITICAL: Failed assertion: ret == 0