ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
nchery has joined #dri-devel
a-865 has quit [Quit: ChatZilla 0.15 [SeaMonkey 2.53.15/20230108172623]]
a-865 has joined #dri-devel
pcercuei has quit [Quit: dodo]
Company has quit [Quit: Leaving]
yuq825 has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
<cmarcelo>
what is virpipe?
srslypascal has joined #dri-devel
<alyssa>
iirc virgl on llvmpipe
<alyssa>
cmarcelo:
<airlied>
nope
<airlied>
it's virgl over a pipe
<airlied>
using drisw
<alyssa>
wild
<cmarcelo>
so, my undestanding is virgl is "OpenGL API that goes through the virtio gpu interface, relies on having something on the other side". so virpipe simulates the other side with LLVMpipe, or some other thing?
<cmarcelo>
(regular "other side" for virgl is the virgilrenderer)
<alyssa>
the virpipe-on-gl job is tagged as mesa-swrast so I assume so
<airlied>
cmarcelo: yeah virglrenderer has a unix socket based server
<airlied>
that is used for testing
<airlied>
and virpipe connects to that
<alyssa>
at any rate, the fails from the virpipe-on-gl job for scoped_barrier seem the same as the llvmpipe ones, so.. yeah
<alyssa>
i expect if you fix llvmpipe the virpipe fails goes away too
<airlied>
but yeah in CI it'll be llvmpipe in the end anyways
camus has joined #dri-devel
<cmarcelo>
alyssa: yes, I'm guessing would be the same
<DavidHeidelberg[m]>
alyssa: mesa-swrast tag meaning is limited to the more powerful runners (more expensive)
<alyssa>
ah
<alyssa>
also why am i thinking about ci on a sunday
<alyssa>
("to avoid thinking about your homework on a sunday" "ah yeah that'll due it")
<DavidHeidelberg[m]>
... sadistic feelings?
<cmarcelo>
airlied: I'm likely missing something here: gallium driver virgl ~~~> unix socket bypass ~~~> virglrenderer, where do we draw virpipe? (I thought it would replace virglrenderer, but seems... not?)
* DavidHeidelberg[m]
looking forward to `venus -> zink`
<DavidHeidelberg[m]>
instead of virgl and virpipe
<airlied>
cmarcelo: no virpipe is just the drisw name for the gallium driver virgl bit
<airlied>
since we have multiple drisw drivers and need names to pick between them, llvmpipe, softpipe, virpipe
<cmarcelo>
let me try again, in the CI: gallium driver virgl ~~~> dri, but we pick drisw [virpipe variant] ~~~> unix socket bypass ~~~> virglrendered, which uses OpenGL ~~~> LLVMPIPE!
<cmarcelo>
airlied: ^
<airlied>
yes that is about right
<alyssa>
man i'm looking forward to the scoped_barrier only future
<alyssa>
I assume anyway that is the end game of this series
<alyssa>
setting use_scoped_barrier for every backend, and then removing the option and memory_barrier_* intrinsics altogether
<cmarcelo>
alyssa: yeah, that's the end game
<cmarcelo>
we have a few steps to go though
<cmarcelo>
i.e. I don't plan to do everything in this particular MR
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<alyssa>
yeah, for sure
<alyssa>
i'll write the {midgard,bifrost,agx} patches of course
<alyssa>
Nominally scoped_barrier should already work for bifrost
<alyssa>
since I hit it with OpenCL
<alyssa>
cmarcelo: ooh, and then renaming scoped_barrier -> barrier since it'll be the only one
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<jenatali>
And hope nobody is rebasing a multi-year-old change that references barrier
<alyssa>
jenatali: rebase conflicts make you stronger? :p
aravind has joined #dri-devel
<jenatali>
It's one thing if it doesn't build but that conflict would be tricky
<alyssa>
jenatali: It wouldn't build
<alyssa>
there's not currently an intrinsic_barrier is there?
<jenatali>
Oh I thought there was
<jenatali>
Nevermind
bmodem has joined #dri-devel
<hays>
what is the most sensible way to get current screen resolution when still on the framebuffer (not in X)
<airlied>
hays: in what way, like inside an application?
<hays>
like when booting and showing a splash screen
<kode54>
some clever emulator author suggested to me that the reason Ryujinx is so slow in some titles on ANV is because ANV is "still optimized for integrated graphics"
<kode54>
(not a Ryujinx dev, but a nosy dev of another project)
<alyssa>
kode54: wdym
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest6017
rsalvaterra_ is now known as rsalvaterra
<kode54>
Soup Odyssey slows to 10-20fps on some areas on an A770, hitting 100% FIFO utilization and maxing out the rendering cores
<kode54>
VBA-M dev Squall Leonhart popped into my bug report to Ryujinx to say that the ANV driver isn't optimized for dedicated GPUs yet
<alyssa>
oh, that I would believe.
<kode54>
it is an interesting point though
<kode54>
considering that in Windows, rather than Intel adapting their Iris drivers to Arc, they started over from scratch
<kode54>
wonder if that would even be worth it for Linux
<kode54>
Xe DG1 may also benefit, since it's a dGPU of a different sort
<kode54>
but hell, that sounds like a nightmare, starting over
Guest6018 has quit [Ping timeout: 480 seconds]
<alyssa>
Not an Intel developer but rewriting ANV seems completely uncalled for
<kode54>
indeed
<alyssa>
I would be unsurprised if the Windows rewrite was due to politics and not perf
<kode54>
maybe someone needs to buy zmike an Arc card
<kode54>
I didn't mean to imply that any of the existing code was bad, but it probably has choke points that uniquely affect dGPUs
<kode54>
maybe
<kode54>
I haven't profiled anything that does particularly bad to see where exactly it's choking
<alyssa>
I stand by ^
<kode54>
politics, indeed
<alyssa>
It is (almost) never warranted to rewrite mature codebases from scratch
<kode54>
I wasn't suggesting a rewrite either
<alyssa>
so if a corporate team does so anyway
<alyssa>
often there are political reasons :p
<kode54>
yeah
<airlied>
also not sure they rewrote their windows drivers from scratch
<kode54>
they certainly ripped out the DX9-11 parts
<kode54>
or made them worse
<airlied>
those are just pieces of the driver stack though
<airlied>
I think their windows d3d12/vulkan drivers might have a lot of common code
<kode54>
probably
<airlied>
and their media stack looks like they forked it inside itself in a horrible nightmare of code duplication
<kode54>
it's a right mess
<kode54>
and they've got the hugest driver package of any vendor right now
<alyssa>
airlied: why are we not shipping anv on Windows again
<airlied>
alyssa: politics :-P
<alyssa>
(-:
<kode54>
of course it is
<alyssa>
oh hey I fixed buffer textures on asahi
<kode54>
neat
<alyssa>
they were broken for like 2 months
<kode54>
oh wow
<cmarcelo>
kode54: I'm not particularly versed on the details of local memory, but: our kernel driver team is working on a new version of the driver https://patchwork.freedesktop.org/series/112188/ (there's a corresponding MR for anv to interface with that) that I expect will get us some improvements in that area.
<alyssa>
in agx/next I mean
<alyssa>
never opend an MR because of said broken
<kode54>
yeah, the Xe KMD
<kode54>
I was following that loosely
<kode54>
I'd definitely be open to actually shoving that into my system when it comes time to test it
<kode54>
assuming it's in a relatively ready state
<kode54>
I've already been running 6.2 since the first RC, building it myself
<kode54>
and running mesa-git with the intel-clc function enabled, also building that myself
<kode54>
well, with PKGBUILDs handily supplied by TkG
<cmarcelo>
kode54: what is the number for the gitlab issue you mentioned above?
<kode54>
oh, sorry, I need to report it on mesa tracker too
<kode54>
I initially reported it to Ryujinx, and forgot to post the Mesa issue
<cmarcelo>
ok
<kode54>
I'll grab the Ryujinx issue and link it on Mesa's tracker
<kode54>
I'll try to be a bit thorough with what I write
<kode54>
oh
<kode54>
someone else already posted an issue
<kode54>
I'll reply to it and track it
alyssa has quit [Quit: leaving]
<kode54>
oh
<kode54>
it was a different game I found by chance
<MrCooper>
bwidawsk cmeissl[m]: FWIW, if the DRM_IOCTL_MODE_ADDFB2 ioctl fails it's an issue on the compositor side, not the client side, so the device sent to clients in dma-buf feedback shouldn't matter
<vsyrjala>
client allocates the buffer does it not?
<MrCooper>
yes, but that can't cause the compositor to use a wrong GEM handle
apinheiro has joined #dri-devel
<MrCooper>
it indicates some kind of mix-up in the compositor process, possibly in Mesa
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
fab has quit [Quit: fab]
kts has joined #dri-devel
kts has quit []
devilhorns has joined #dri-devel
fab has joined #dri-devel
ice9 has joined #dri-devel
<kode54>
god dammit
urja has quit [Read error: Connection reset by peer]
<kode54>
why does CONFIG_DRM_XE have no special requirements, but CONFIG_DRM_XE_DISPLAY requires CONFIG_EXPERT
urja has joined #dri-devel
<kode54>
I guess it doesn't assume I would be using a pre-baked distribution configuration as my starting template
junaid has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
<mlankhorst>
danvet: ping?
<digetx>
jani: hi, please let me know if you still have that shmem conflict because I don't have it (maybe I'm doing something wrong?)
<vsyrjala>
happens here too. currently on git 2.39.2, should that make a difference
<vsyrjala>
last drm-tip rebuild was on 25th, but the conflicting stuff was pushed on 27th. so i guess you didn't actually rebuild drm-tip?
<digetx>
have the same git version; when I run `./dim rebuild-tip; cd drm-tip; git diff`, it gives me conflicts for i915 and amdgpu only
<jani>
digetx: still seeing it
<vsyrjala>
digetx: so maybe you have a local conflict resolution for this in you rerere, but never pushed since you stopped the rebuild when encountering some i915/amdgpu conflicts?
<jani>
digetx: given the conflict in the paste, is just choosing the latter part the right resolution?
<jani>
apparently not, doesn't build
neobrain has quit [Ping timeout: 480 seconds]
alatiera4 has joined #dri-devel
alatiera has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
<digetx>
let me try to re-setup the maintainer-tools
<jani>
but why?
<digetx>
don't see any local conflict resolutions
apinheiro has quit [Ping timeout: 480 seconds]
alatiera4 is now known as alatiera
<kode54>
I tested the Xe KMD
<kode54>
it can't find any functioning crtc
apinheiro has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
tzimmermann has joined #dri-devel
<daniels>
cmeissl[m]: yeah, so the root of your issue is that FD_TO_HANDLE is failing. that's telling you that you can't import the dmabuf into your scanout device. anything beyond that is not going to give you good results. it sounds like this is being caused because platform_wayland isn't invoking the kmsro infrastructure to make it aware of the scanout device as well. probably a bunch more typing required there. this does work for most
<daniels>
devices, but i.MX6 is just the worst possible case.
<jani>
digetx: no matter what, the last drm-tip rebuild as well as last drm-rerere update was 2023y-02m-25d-19h-52m-27s UTC
<daniels>
hakzsam: I know people were busy last week, so I've kicked again
<daniels>
hakzsam: tintou is looking into itnow
<jani>
tzimmermann: mripard: mlankhorst: please look into getting the conflict between drm-misc branches resolved
* jani
.oO( if we were doing gitlab merge requests, it could warn in advance that merging something will cause a drm-tip rebuild conflict instead of after the fact )
<tzimmermann>
jani, looking...
fab_ has joined #dri-devel
fab_ is now known as Guest6057
anarsoul|2 has quit [Read error: Connection reset by peer]
anarsoul has joined #dri-devel
<tzimmermann>
jani, fixed
<tzimmermann>
the problem is that people land their patches and then walk away without looking for errors in the merge process
fab has quit [Ping timeout: 480 seconds]
<hays>
was going to ask again, sorry for the repeat, but i am curious if anyone can recommend tools or methods to get screen resolution and sizing reliably before X is running?
<hays>
i found fbset which is a little helpful, but I dont have an /etc/fb.modes
<hays>
am trying to (1) find out which device is connected (2) what the maximum or recommended resolution is, set that resolution
<cmeissl[m]>
MrCooper daniels thanks! yes, I did try calling primeFdToHandle directly and it indeed already fails, so the failure of drmModeAddFB2 is to be expected. So I was on the right track with kmsro at least. From the code I am not sure how kmsro is expected to work in combination with dmabuf feedback. When I send the render node from etnaviv (renderD128) as the main device it will happily use dmabuf feedback, and also set the required
<cmeissl[m]>
`__DRI_IMAGE_USE_SCANOUT` flag if a scan-out tranche is sent, but it won't initialize kmsro. Sending card1 (imx-drm) as the main device will initialize kmsro, but disable dmabuf feedback and fallback to wl_drm. I guess that is caused by `loader_get_render_node` returning NULL in `default_dmabuf_feedback_main_device`.
Company has joined #dri-devel
<digetx>
tzimmermann: hoped that refreshing of maintainers-tool will help (it's fetching src git a bit too slow), not sure why I don't see that conflict
<cmeissl[m]>
And am I right, that as long as the client does not initialize kmsro it is expected to fail?
<tzimmermann>
no idea
<digetx>
now I'm thinking that I may've had a local remote branch that helped to resolve the conflict
<tzimmermann>
digetx, how old is your git. IIRC older git versions don't deal well with new tools. but i don't remember the exact problems they had
<vsyrjala>
i don't rebuild-tip should use local branches (apart from rerere)
<vsyrjala>
i don't think...
<tzimmermann>
yeah, the local branch does not affect the merging
<vsyrjala>
../drivers/gpu/drm/drm_gem_shmem_helper.c:651:15: error: implicit declaration of function ‘drm_gem_shmem_get_pages_locked’; did you mean ‘drm_gem_shmem_get_pages_sgt_locked’? [-Werror=implicit-function-declaration]
fab has joined #dri-devel
<jani>
<jani> apparently not, doesn't build
<jani>
<jani> digetx: given the conflict in the paste, is just choosing the latter part the right resolution?
<jani>
the same error : |
<jani>
pro-tip, when resolving something in drm-tip, just do make olddefconfig; make path/to/conflicting/file.o
<jani>
before actually committing
<vsyrjala>
i just test build the whole thing
<digetx>
jani: yes, the pages_lock is replaced with the resv lock
<digetx>
the drm_gem_shmem_get_pages_locked isn't correct, though
<digetx>
jani: but both next and next fixes have ddddedaa0db9
<danvet>
mlankhorst, back from vacations
fab has quit [Quit: fab]
fab has joined #dri-devel
<vsyrjala>
emersion: creating the props should be fine. but attaching props you don't support would be wrong
<emersion>
ah
YuGiOhJCJ has joined #dri-devel
<emersion>
hm, weird, gud seems to support tv_brightness but doesn't expose it
<emersion>
doesn't attach it*
<emersion>
the only driver to attach it is ch7006
aravind has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
Haaninjo has quit [Ping timeout: 480 seconds]
<digetx>
jani: now I see that it's actually drm/drm-next that fails to merge for drm-tip and not misc-next, do you have conflict resolution for drm-next? or how it all works, what am I missing :)
nchery is now known as Guest6063
nchery has joined #dri-devel
Guest6063 has quit [Ping timeout: 480 seconds]
<jani>
digetx: drm-tip rebuild (regeneration) works fine now; unfortunately the actual build fails due to the wrong conflict resolution
<jani>
digetx: are you new to dim?
<jani>
no value judgement there; just checking the facts ;)
<DavidHeidelberg[m]>
mupuf: 👀curl for the container, pretty please :P
<digetx>
jani: kind of new to dim, yes; I can apply patches with dim, but skipped the drm-tip part because previously all the conflict were complicated and irrelevant to my changes
kts has joined #dri-devel
<jani>
digetx: well, basically applying patches with dim must include addressing any resulting conflicts in drm-tip rebuild. whoever applies patches and it causes conflicts in drm-tip rebuild is on the hook for either resolving them or pulling in folks to help
<jani>
digetx: if you leave them unresolved, the conflicts pile up as people apply more, and it gets harder
<vsyrjala>
hmm. could we make dim do a test rebuild-tip _before_ pushing anything new? would prevent conflicts from piling up and thus making it hard for any single person to resolve the mess
<jani>
if you develop on top of drm-tip, and send patches from there, and they fail to apply to an individual branch, it's a good indicator a conflict will occur
<jani>
vsyrjala: it's racy, as is the current approach
<jani>
adding the local build of drm-tip makes the race window longer
itoral has quit [Remote host closed the connection]
<digetx>
seems I figured out what was going on wrong all that time.. I had rerere disabled in my .git global config
<vsyrjala>
jani: i suppose. though i don't think our usual problems have been due to the racyness. more because people forget to check the results of the rebuild
<vsyrjala>
another idea could be to have ci/something complain if drm-tip is lagging behind
<zmike>
mareko: did you have issues with the tc query MR or just questions
<digetx>
jani: finally, I've the drm_gem_shmem_get_pages_locked -Werr after fixing rerere \o/
<jani>
digetx: right, maybe send a patch to dim to check that config ;)
nchery is now known as Guest6065
nchery has joined #dri-devel
neobrain has joined #dri-devel
<jani>
vsyrjala: I've had some ideas wrt that, it could flag the conflicts and identify which patch/push caused it and everything, but it's the kind of yak shaving that doesn't just happen :(
Guest6065 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
<digetx>
jani: so that drm_gem_shmem_get/put_pages_locked build error in drm-tip now is due to a wrong merge conflict resolution? should me/we do anything about it?
<vsyrjala>
you need to revert that from rerere, and then do it right
Zopolis4 has quit []
fxkamd has joined #dri-devel
agd5f_ has joined #dri-devel
<nroberts>
does anybody know if the Intel CI has a rust compiler? would it be a pain if the rust port of vkrunner was merged into the master branch? it would at least have to be updated to build using ninja instead of cmake
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
<digetx>
jani: vsyrjala: should be fixed now
<nroberts>
I mean meson
<vsyrjala>
digetx: builds now. thanks
agd5f_ has quit [Ping timeout: 480 seconds]
<digetx>
awesome, thank you all! the disabled rerere in my git confit was very obscure and confusing to me
<vsyrjala>
digetx: btw i see you ended up with some extra reverts in rerere. 'dim -d rebuild-tip' is useful when messing about with conflicts. i always use that until i have it fully nailed down, and then drop the -d for the final rebuild
<digetx>
indeed, missed the dry-run option, thanks
<daniels>
cmeissl[m]: the client needs to receive etnaviv as the main device indeed, because etnaviv _is_ the main device - it's the fallback which is used for composition in case it's not possible to use planes, so the buffers always need to be accessible to etnaviv. I think the optimisation is substantially reworking the DRIScreen/pipe_screen/kmsro/etc integration so that we can pass preferred_device down to the driver layer, and it can
tobiasjakobi has quit [Remote host closed the connection]
<eric_engestrom>
DavidHeidelberg[m]: yes, sorry I was off on friday for a long weekend and I haven't gotten around to that MR yet, but I'll add the r-b and marge in a minute
<mupuf>
DavidHeidelberg[m]: yeeeees! On it now :)
<DavidHeidelberg[m]>
all good news, I love this chat :D
<DavidHeidelberg[m]>
eric_engestrom: hope you enjoyed the weekend to the 100% ;-)
zehortigoza has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
sse2 fixes got it, armv7 lto workaround awaits, android fix to be merged, mold fix in main branch should probably solve LTO fail when linking release build. Life is great.
<eric_engestrom>
:D
yuq825 has quit []
kts has joined #dri-devel
jkrzyszt has joined #dri-devel
<cmeissl[m]>
daniels: oh, that doesn't sound like the easiest thing for someone still pretty unfamiliar with the inner workings of mesa. but, yes, using the target tranche device sounds like the best solution. out of curiosity I patched loader_get_render_node to return the primary node if no render node could be found and changed the feedback in the compositor to use card1 as the main device. Both paths, scan-out and composition, still work.
Haaninjo has joined #dri-devel
mbrost_ has joined #dri-devel
fxkamd has quit []
mbrost has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
fab has quit [Quit: fab]
Haaninjo has quit [Ping timeout: 480 seconds]
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
orbea has joined #dri-devel
mbrost__ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
fab has joined #dri-devel
Leopold_ has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
bmodem has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
devilhorns has quit []
zehortigoza has joined #dri-devel
<karolherbst>
could somebody look at why gc2000_piglit times out
<karolherbst>
probably serial console spam.. anyway, would be nice if somebody looks into it
<karolherbst>
zmike: already aware of the UnexpectedPass with zink?
<eric_engestrom>
karolherbst: if you leave them in the fails as well, that means they only get reported as flakes when they pass, which I think is rare
<eric_engestrom>
(aka less #zink-ci spam)
apinheiro has joined #dri-devel
Haaninjo has joined #dri-devel
genpaku_ has quit [Read error: Connection reset by peer]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
genpaku has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
stuart has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
nukelet_ has quit []
djbw has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
kzd_ has joined #dri-devel
smiles has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
<marex>
I am curious, there is a patchset which adds support for feeding multiple encoders->bridges from single crtc for lcdif driver , is that something that one can really do ?
<marex>
mripard: ^
<marex>
my understanding is they read the same base plan using crtc and then pump it out into some "tee" which feeds the encoders and then bridges, all of them with the same data, at the same time
<mareko>
zmike: both
<marex>
I am a bit hesitant to review that stuff
<mripard>
I have no idea whether the hardware is capable to do it
<mripard>
but KMS definitely can
<zmike>
mareko: ok, I am awaiting your followup with bated breath
jhli_ has quit [Remote host closed the connection]
<javierm>
robclark, danvet: what if instead of adding a CONFIG_DRM_VIRTIO_GPU_KMS kconfig symbol, the driver is changed to only disable the KMS part with "nomodeset" ?
<javierm>
that way you could just boot your guest VM with virtio-gpu.modeset=0 or nomodeset
<danvet>
yeah that might be a notch cleaner solution for the one-off-custom-built-distro case
<danvet>
it won't work in general, e.g. if you also pass through an actual virtualized display and not virtio-wayland
jhli has joined #dri-devel
<robclark>
hmm, I guess that fits the name, but diverges a bit on how other drivers interpret nomodeset
<danvet>
since that would then also get disabled
<danvet>
robclark, i915 did it like that in the good old days of ums gem support :-)
<javierm>
robclark: not really, in fact many drivers only disable KMS with nomodeset
unerlige has left #dri-devel [#dri-devel]
<javierm>
robclark: in fact, DRM only drivers just ignore that option
<danvet>
yeah plus that
<robclark>
hmm, well, I could *also* possibly add modparam option.. but the build option still works best for us
unerlige has joined #dri-devel
<javierm>
robclark: right, not strong opinion for me. I just wanted to point out that there could be an alternative approach :)
<javierm>
regardless, it would be good if all drivers only disable KMS with nomodeset instead of just failing to probe
<robclark>
the build option is less subtle, and that makes it easier for folks triaging bug bounty program reports
<anholt_>
sergi: what's the deal with the piglit uprev mrs being testonly and getting closed? I would really like to see piglit updated, but I haven't done it because you're clearly working on it, but you keep closing them.
<marex>
mripard: btw may I ask you to be a bit more patient with Jagan ? The samsung patches are in like v14 now, it would be really good to finally get those merges, and I think there is like one single outstanding issue now
<mripard>
a single outstanding issue we've been discussing since v9 iirc
<mripard>
and that he always ignored
<mripard>
and he managed to ignore it in both submissions he did today
<marex>
mripard: I am aware of that, but I'm afraid stomping on it with NAK isn't going to achieve the right outcome
<mripard>
so no, sorry, I believe I've already been more than patient on this one
<marex>
mripard: lemme have a look at that discussion again
<mripard>
I mean, it was a NAK unless you change it
<mripard>
if he changes it, then I'll happily reconsider it, and I already provided what he needs to change it and make me happy
<mripard>
at this point, I'm not sure what I can bring to the discussion, hence why I wrote that.
hansg has joined #dri-devel
<marex>
mripard: is my understanding correct, that all he has to do is s@devm_@drmm_@ ?
<marex>
hm, no ...
<sergi>
anholt_: the bot is trying uprev_piglit_in_mesa every night but some jobs doesn't produce artifacts when uprev piglit. In a case like that, what the bot does is to create an issue in the target project (aka mesa) https://gitlab.freedesktop.org/mesa/mesa/-/issues/8360
<mripard>
marex: he needs to move the call to drm_of_find_panel and bridge to bind
<mripard>
first
<mripard>
then create the drmm helper you were mentioning
<mripard>
and this whole dance to work around the fact that you don't have a pointer to the drm device is moot
<anholt_>
sergi: so you just keep opening and closing MRs, and then what's supposed to happen? Are you investigating those issues?
<marex>
mripard: to ... bind ?
<marex>
mripard: or to samsung DSIM driver probe ?
<marex>
mripard: which bind ?
<marex>
struct mipi_dsi_host_ops has no ->bind callback
<marex>
I do see of_drm_find_panel() used in driver probe callbacks however
<mripard>
to exynos_dsi_bind
<sergi>
anholt_: MRs with the tag "testonly" are from my user while testing the tool. The bot is running it every night and should create MRs without this tag. In case the bot cannot complete the process, it creates an issue trying to explain. At this point, who will integrate an uprev proposal would come from one that knows more than I. About investigating the cause of the issue, you are right, I can do that. At least start, and request help in case I
<sergi>
don't know more.
<marex>
but wait, that's outside of this driver, the DSIM bridge driver can also be used by i.MX 'lcdif' and 'mxsfb' drivers
<marex>
er, please ignore that
<marex>
mripard: actually, no, dont ignore that ... should the drm_of_find_panel also go into samsung_dsim_register_host ?
<marex>
mripard: as far as I understand it now, drivers/gpu/drm/exynos/exynos_drm_dsi.c is the Exynos glue code , samsung_dsim_register_host and co is the i.MX glue code
<mripard>
marex: you can't use drm_of_find_panel or its bridge variant
<mripard>
I mean, you can, DSIM is the proof of that, it's just broken.
<mripard>
and you can end up in probe deadlocks depending on the situation
<marex>
mripard: let's just focus on the first part , i.e. the "move ... to bind", first
<marex>
mripard: and then second which exact function to use
<sergi>
anholt_: would be nice if we (together) can think in a workflow. I have an idea about the thinks that could be made automatically with the "post" uprev section https://gitlab.freedesktop.org/gfx-ci/ci-uprev/-/issues/27 But there are things, like what you mention about investigate the issue, that requires a human
<mareko>
radeonsi can't fully switch to scoped barriers due to differences between LLVM and ACO
<marex>
mripard: so do I understand it right that the ... drm_whatever_panel ... should be called from both exynos_dsi_bind() and samsung_dsim_register_host() ?
<marex>
basically before mipi_dsi_host_register() ?
<cmarcelo>
mareko: what information is missing in the scoped barrier?
<mripard>
samsung_dsim_register_host isn't in the current source tree, so I don't know for that one
<mripard>
but it must be called at bind time
<marex>
mripard: so do I understand it right that the ... drm_whatever_panel ... should be called from both exynos_dsi_bind() and samsung_dsi_register_host() ?
<marex>
errr ...
<mripard>
drm_whatever_panel must be called at bind time
<marex>
mripard: try generic_dsim_register_host
<marex>
... which is called at ... ugh
<mripard>
not in 6.2 either
<marex>
mripard: its in patch v13 14/18
<mripard>
but how the driver is organized is pretty much orthogonal. If that function is called directly by the driver bind, then fine
<anholt_>
sergi: my workflow recommendation would be: drop [TESTONLY] from the MR title once your testing and conclusion-writing process is done, but keep the MR open. Then people can see it. Report the problems in the MR instead of an issue, because that text is only really useful in the context of the MR. Also, s/TESTONLY/WIP/ would make more sense.
<mripard>
if it isn't, then it's pbroken
<marex>
mripard: its actually called from platform driver ->probe callback
<mripard>
and in 14, samsung_dsim_host_attach isn't bind either
<sergi>
anholt_: The "testonly" tag is from local executions on my machine or from a pre-merge pipeline in ci-uprev (this project uses also marge and tries the uprevs). But those MRs with this tag are only experiments, not made to be used later. The gfx-ci-bot has an scheduled pipeline each midnight (in UTC terms) and creates what we may call "production" MRs for uprev. Those are real candidates.
<mripard>
mipi_dsi_host_register is called at probe time, which isn't bind?
<marex>
mripard: yes, that's called at probe time
<mripard>
then no?
<marex>
mripard: so ... which bind ?
<marex>
mripard: just, point me to the structure name I am looking for
<sergi>
anholt_: But yes, in this case, I'm seeing that I was producing uprev candidates since enter in production. And after that, this piglit uprev starts having trouble with some jobs and their artifacts creation.
<mripard>
marex: it's late, it's a driver I don't know, patches I wasn't cc'd for
<mripard>
I'm not going to dig into a 15 patches series
<sergi>
anholt_: I'll review why those jobs are failing and see if there is something I can do, or ask for help
<marex>
mripard: mipi_dsi_host_ops doesnt have a bind callback
<marex>
mripard: OK, understood, and thanks for the example, that helps a great deal
<marex>
mripard: but there is one more problem here, the imx side doesn't use the component stuff
alyssa has joined #dri-devel
<alyssa>
23:53 <gfxstrand> The other thing is that the pass right now assumes your back-end uses it for everything. It takes bytes rather than a (bit_size, num_components) pair as the input to the callback. It doesn't distinguish between, say, a u8vec4 and a uint if they're both 4B aligned. That's fine for all the HW I'm familiar with, though.
<alyssa>
23:53 <gfxstrand> Maybe not the most friendly for API translation but fine for HW.
<alyssa>
It does lead to some silly things, though
<mripard>
marex: then I think you can get away with it by calling it in probe
<sergi>
anholt_: I think it didn't have the opportunity to create a single one in production
<alyssa>
Like an aligned u16vec4 turning into a u32vec2 and a pile of unpacks
<marex>
mripard: ahhhhhh
<mripard>
so I guess you'd need two callbacks, one supposed to be called in probe, the other in bind
<marex>
mripard: THANK YOU
<mripard>
exynos would call the probe callback in its probe, and the bind in its bind
<marex>
mripard: I think I understand it now
<alyssa>
This shouldn't be a problem for AGX since we can coalesce away all the packs
<alyssa>
*unpacks
<mripard>
while imx would call both the probe and bind callbacks in its probe
<mripard>
that would probably work
<alyssa>
IDK if the Bifrost compiler is that smart.
<alyssa>
gfxstrand: ^ sorry that got split up across threads
<mripard>
but I'd still test those odd cases in the documentation on imx
lynxeye has quit [Quit: Leaving.]
<marex>
mripard: I'll try to summarize that and provide feedback ... and, I cannot test on exynos, so all my tests happen on imx
<marex>
mripard: that part should be covered at least
<sergi>
anholt_: I see the source of the problem. I hope I'll have a solution soon
<marex>
mripard: and the function name would them be still of_drm_find_panel() or some drmm_ variant ?
<mripard>
it doesn't really matter, it'd be better to use a drmm function straight away, but if you don't want a managed version that's fine too
<mripard>
a device managed version is not really an option though
<marex>
so unbind has to do clean up?
<marex>
mripard: OK, mail is out, let's see what happens
<marex>
mripard: thanks for clarifying this to me
dviola has quit [Quit: WeeChat 3.7.1]
<mripard>
you're welcom
<gfxstrand>
alyssa: If there's genuine value in doing so, we could make the callback take an actual (bit_size, num_components) pair. It's just a bit of a pain to maintain that in the case where we end up splitting something into multiple loads.
<gfxstrand>
I guess we could always reduce everything to the smallest bit-size you've ever requested or something dumb like that.
<gfxstrand>
And so far, I've primarily worked with two flavors of hardware that need this sort of splitting:
<gfxstrand>
1) AMD/Intel where there's a scalar unaligned load/store that needs to be used for align < 4 and a 4B-aligned vector load/store which you use for everything else.
<gfxstrand>
2) NVIDIA where load/store operate on any power-of-two size from 1B to 16B and it requires the same alignment as the amount of data being accessed.
<gfxstrand>
In both cases, they're happy to eat a bit of pack/unpack.
phasta has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
nchery has joined #dri-devel
junaid has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
ybogdano is now known as Guest6101
ybogdano has joined #dri-devel
Prax has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
Prax has quit [Remote host closed the connection]
Pr4x has joined #dri-devel
Pr4x has quit [Remote host closed the connection]
Zopolis4 has joined #dri-devel
<alyssa>
gfxstrand: Yeah that's valid
<alyssa>
AGX/Mali are class #2 generally speaking
junaid has joined #dri-devel
gouchi has joined #dri-devel
<alyssa>
Well, Mali is #2
<alyssa>
AGX is 1B/2B/4B elements requiring natural alignment and you can do up to 4 of them at a time
<gfxstrand>
Ok, that's a bit weird
<alyssa>
meh, it's basically spicy #2
<jenatali>
DXIL looks like AGX too
<alyssa>
jenatali: obviously, everyone knows that Direct3D was designed for Apple GPUs right?
<jenatali>
Obviously
<alyssa>
or was it Apple GPUs designed for Direct3D?
<alyssa>
i forget
* alyssa
adjusts tinfoil hat
<gfxstrand>
I mean, if someone wants to figure out what the loops should look like operating on bits/comps instead of raw bytes, I'm not opposed.
<alyssa>
I don't think there's any benefit for AGX
<alyssa>
but I haven't thought about this in too much detail
<gfxstrand>
I doubt there's much benefit to DXIL, either, given that it's going to get converted right back into one of the two modes by the client driver anyway.
junaid_ has joined #dri-devel
<alyssa>
Provided that we can coalesce the unpacks, I imagine i32vec2+unpack is equal perf to the original i16vec4
<gfxstrand>
probalby
<alyssa>
(Just carrying the restriction that it needs 4 byte alignment instead of 2)
<gfxstrand>
But that's for RA to sort out
<gfxstrand>
And RA is magic
<alyssa>
Oh... and it requires its destination to be 2-reg aligned instead of unaligned
<alyssa>
which (once RA is competent) does not affect register pressure but might result in extra moves/shuffles due to unnecessary live range splitting
junaid has quit [Ping timeout: 480 seconds]
junaid__ has joined #dri-devel
<alyssa>
basically where I'm at is, I think the splitting logic is fine in the cases we really do need to split
<alyssa>
but it's a bit of a blunt hammer that ends up splitting for instrucitons that didn't actually need the split
<alyssa>
if I could filter on (num components, bitsize) but do splitting in terms of bytes, that'd probably be good enough 99% of the time
<alyssa>
as it is, I don't think I can distinguish i64 scalar loads (which need to be split) from i32vec2 and i16vec4 loads (which don't)
<alyssa>
(for the RA friendliness, possibly I could promote i32vec2 loads to i16vec4 at isel time. but that'll probably be worse overall because you really did want the alignment when the result is used as a 32-bit scalar)
<gfxstrand>
I think today's project is parallel copy lowering.
<alyssa>
Seems legit
<alyssa>
I copypasted cwabbott's code, twice
<alyssa>
Works like a charm
<alyssa>
Even added unit tests
<gfxstrand>
I should probably look at how ACO does it and use a better data structure so Daniel doesn't chide me for chosing confusing algorithms. 😅
<alyssa>
who cares what data structure you use
<alyssa>
this isn't exactly a hotspot :p
junaid has joined #dri-devel
<alyssa>
Vec<all the things!>
flto has quit [Remote host closed the connection]
junaid___ has joined #dri-devel
<gfxstrand>
lol
<gfxstrand>
More that the NIR impl aparently confuses people.
junaid__1 has joined #dri-devel
flto has joined #dri-devel
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
<mareko>
cmarcelo: no information as far as I know
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<cmarcelo>
mareko: can you elaborate on the differences between ACO and LLVM you were talking about earlier?
<mareko>
cmarcelo: nir_var_shader_out in the scoped barrier is handled differently between ACO and LLVM
<DemiMarie>
Would Mesa be better off without using LLVM for AMD and just generating AMD shader machine code directly?
<gfxstrand>
Oh, you mean like RADV does with ACO?
<gfxstrand>
DemiMarie: ^^
<gfxstrand>
DemiMarie: I think that depends on who you ask. 😅
<DemiMarie>
gfxstrand: no idea what RADV or ACO mean
<gfxstrand>
RADV is the Vulkan driver for AMD HW that's in Mesa.
<gfxstrand>
ACO is the non-LLVM back-end compiler it uses.
<gfxstrand>
DemiMarie: Short version is that all the big pieces are in place such that radeonsi could switch over. Some work would have to be done to get ACO working with GL. It's got some Vulkan or RADV assumptions in it today and radeonsi has a bunch of LLVM assuptions.
<gfxstrand>
Nothing that isn't fixable.
pa- has quit [Read error: Connection timed out]
<gfxstrand>
But various parties have differing interests so there hasn't been a concerted effort to make it happen.
<DemiMarie>
Will Zink eventually be the only OpenGL driver?
pa has joined #dri-devel
<jenatali>
Doubtful
<DemiMarie>
Is this for performance reasons?
<pixelcluster>
gfxstrand: iirc aren't there some people working towards ACO with GL?
<pixelcluster>
I think I remember seeing MRs hinting that
<gfxstrand>
pixelcluster: There's been various people who've chipped away a bit.
<pixelcluster>
I see
<zmike>
I'm using it with GL every day!
<DemiMarie>
What advantages does ACO have over LLVM?
<ccr>
I have no idea, but I'd bet one of the biggest advantage is that it's not LLVM :P
<gfxstrand>
hehe
<gfxstrand>
Probably the biggest advantage is that it's blazingly fast
<gfxstrand>
While LLVM is a bit of a pig.
<gfxstrand>
I think the AMD folks have gotten their LLVM compile times manageable but it's still LLVM.
<DemiMarie>
Also LLVM aborts on OOM.
<DemiMarie>
Are LLVM’s optimizations useful here?
<alyssa>
gfxstrand: hey that's mean
<alyssa>
to pigs
alyssa has quit [Quit: leaving]
<gfxstrand>
alatiera: :P
<gfxstrand>
alyssa, rather
fab has quit [Quit: fab]
junaid__ has quit [Remote host closed the connection]
junaid__1 has quit [Remote host closed the connection]
junaid___ has quit [Remote host closed the connection]
junaid_ has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
lemonzest has quit [Quit: WeeChat 3.6]
hansg has quit [Quit: Leaving]
Haaninjo has quit [Quit: Ex-Chat]
jkrzyszt has joined #dri-devel
<agd5f>
DemiMarie, LLVM has a lot of useful stuff for compute (e.g., support for functions, and eventually debugger support with GDB) that may be useful for gfx eventually.
<gfxstrand>
We should start seeing functions pop up in NIR compilers before too long, I think.
<jenatali>
I'd love to see debug data support come through
<jenatali>
Not looking forward to writing the PDB writer for DXIL but I am looking forward to source-stepping
<gfxstrand>
Yeah, I need to go see where that's at.
<gfxstrand>
I know there were some NIR patches. I gave some comments. Some things happened. IDK where they're at now.
ice9 has quit [Ping timeout: 480 seconds]
Guest3910 has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Leopold___ has joined #dri-devel
<karolherbst>
yeah, let's ditch llvm, it's a constant pain 🙃
heat has joined #dri-devel
<karolherbst>
(still wants to see aco hooked up in radeonsi)
<karolherbst>
gfxstrand: it essentially works, I might have one or two patches, but nothing huge
<karolherbst>
there are two bigger issues I'm seeing with proper function support in nir
<karolherbst>
1. a proper function inlining pass
<karolherbst>
2. backends
Leopold_ has quit [Ping timeout: 480 seconds]
<agd5f>
modulo dealing with the DWARF standards body, we have GDB support in branches today, at least for compute, more or less on par with what you'd get from a CPU
<danvet>
airlied, you need to fix your dim setup so no copypasting is needed, dim gets the subject right :-P
<gfxstrand>
karolherbst: Those are a couple of load-bearing issues you've got there. 😅
<airlied>
danvet: oh I don't use dim to send the pull requests
<airlied>
because I don't use mutt
<karolherbst>
gfxstrand: yeah.. guess why I didn't started to look into it yet :)
<danvet>
airlied, ask jani
<airlied>
I only use dim to produce the pull request txt
<danvet>
yeah I know :-)
<airlied>
but I don't want to use dim to send me PR either
<karolherbst>
though I still plan to do the work for llvmpipe + radeonsi and see where it goes
<karolherbst>
but other drivers will probably have to do the work themselves
<airlied>
I write it up in gmail, but yes the subject line is my defeat
<danvet>
iirc what jani has done is do a little script to drop the output of dim into a draft or something suitable for whatever thing you're using
<danvet>
but that was for notmuch
bgs has quit [Remote host closed the connection]
<danvet>
and set that script as DIM_MUA
<airlied>
I could have it email me I suppose and then edit the email before sending it on
<danvet>
fwd: [GIT PULL] drm-next would be hilarious
<airlied>
yeah I'd still find a way to screw it up
<jani>
danvet: I actually upstreamed a notmuch-emacs-mua script to mimic mutt cli interface for composing. it generates the email, but I can edit and hit send at my leisure after that
* airlied
doubts there's a neat gmail integration here :-P
<jani>
airlied: I'm sure it's just a SMOP
* airlied
can't even spawn firefox since it's a remote machine
<airlied>
jani: indeed!
<jani>
it could be a merge request on gitlab where some action generates and sends the pull request mail
<airlied>
yes that would be a later dream :-P
apinheiro has quit [Quit: Leaving]
<jani>
the sad part is, this is all just git, with a lossy medium in between
<jani>
and pr-tracker-bot is a hack that monitors and cross-references a mailing list and a git repository
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<jenatali>
Question for a Vulkan expert: Is it valid to dynamically index between samplers that are bound to a pipeline as immutable samplers?
<gfxstrand>
yes
<gfxstrand>
They're just samplers
<gfxstrand>
From a shader POV, they're not different.
<gfxstrand>
Unless you're doing YCbCr
<jenatali>
Alright
<jenatali>
D3D puts a restriction there FWIW
<gfxstrand>
I guess it's possible Vulkan has some but I'm unaware of them.
<gfxstrand>
They do get weird around descriptor buffers.
<gfxstrand>
IDK why we allowed the two to interact, TBH. We should have just killed off immutable samplers except for YCbCr.
<jenatali>
Yeah
* jenatali
shrugs
<Wallbraker>
Arg I can't remember the name for the thing, but like everything in a execution wave needs to select the same sampler.
<jenatali>
Dynamically uniform
<Wallbraker>
That's that the!
<Wallbraker>
the name*
<jenatali>
Alright well then I guess I'll have to not map them to static samplers when supporting descriptor_indexing
<jenatali>
Oh well
nchery has quit [Ping timeout: 480 seconds]
<Wallbraker>
I would check the spec, as my memories is very hazy here.