ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
digetx has joined #dri-devel
<jenatali>
gfxstrand: I don't know too much about what Vulkan can do, but DXIL at least can do 4-component vectors of 16bit, 32bit, 64bit for SSBOs, and 16-byte UBO (4-component 32bit, 2-component 64bit, 8-component 16bit)
<jenatali>
UBOs need to always be 4-byte-aligned currently
<jenatali>
But yeah I think just letting the callback return 0 makes more sense
<gfxstrand>
jenatali: So would you want it to take a (bit_size, num_components) pair as input, then? So you can tell the difference between a u8vec4 and a u32?
<jenatali>
gfxstrand: It doesn't matter as long as it has alignment
<gfxstrand>
kk
<gfxstrand>
Ugh... I'm now remembering why I made it in bytes
<jenatali>
At 1-byte alignment, we can load nothing :P, at 2-byte alignment we can load up to 8 bytes, etc
<gfxstrand>
jenatali: Ah, makes sense.
<gfxstrand>
jenatali: Well, with the latest version of that MR (Yeah, I know, I keep adding stuff), you can look at a 1B alignment and 6B of data and say "use a u32vec4" and it'll do all the things.
<gfxstrand>
jenatali: No support for doing that via stores yet. You'll have to write that.
<jenatali>
Yeah, I'll port the stores aspect over
<jenatali>
... eventually
<jenatali>
Today's been crazy, you good if I re-review on Monday?
nchery is now known as Guest5781
Guest5781 has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
<gfxstrand>
Oh, sure
<gfxstrand>
It's 6PM here anyway
<jenatali>
Cool. I'll probably forget, but feel free to ping me (or just push more stuff to it so I get emails about it again :P)
sarnex has quit [Read error: Connection reset by peer]
sarnex_ has joined #dri-devel
kts has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
ZenWalker has quit [Ping timeout: 480 seconds]
ZenWalker has joined #dri-devel
<bwidawsk>
How does the kmsro kms_fd normally get setup? It looks like it should be automatic, but I can't seem to figure it out
<bwidawsk>
vc4 seems to be the only driver with a specific path for it
rasterman has quit [Quit: Gettin' stinky!]
<DavidHeidelberg[m]>
Please check this magnificent beast MR. It's about using sections trough all devices, builders, runners.. etc. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20272 (CI passed in mine fork, now it's running in the mesa/mesa)
Leopold___ has joined #dri-devel
anarsoul|2 has joined #dri-devel
<DavidHeidelberg[m]>
I would love to merge it monday, tuesday, since it's complex and needs rebasing against main often :)
<bwidawsk>
like, what's supposed to call kmsro_drm_screen_create()?
hansg has quit [Quit: Leaving]
* bwidawsk
is lost in drm-helper magic
anarsoul has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
gouchi has joined #dri-devel
konstantin has joined #dri-devel
konstantin_ has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: leaving]
kts has quit [Quit: Konversation terminated!]
Sofi[m]1 has quit []
Sofi[m]1 has joined #dri-devel
heat has quit [Remote host closed the connection]
Sofi[m]1 has quit []
Sofi[m]1 has joined #dri-devel
Sofi[m]1 has quit []
Sofi[m]1 has joined #dri-devel
Sofi[m]1 has quit []
Sofi[m]1 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
<robclark>
bwidawsk: see drm_helper.h
aissen_ has joined #dri-devel
aissen has quit [Remote host closed the connection]
<bwidawsk>
robclark: I still don't see how it's supposed to get called
<robclark>
from pipe_kmsro_create_screen()
<robclark>
ptr to that ends up in a `struct drm_driver_descriptor`
cmeissl[m] has joined #dri-devel
<cmeissl[m]>
Hi, bwidawsk is helping me understand if and how direct scan-out should work for wayland clients when etnaviv is in use on the i.mx6. So far I can tell that dmabuf feedback is sending a scan-out tranche with linear and the driver re-allocates from a tiling format to linear. But in the compositor the call to drmModeAddFB2 with the imported buffer from gbm always fails (drm log shows "Failed to lookup GEM object"). PIPE_BIND_SCANOUT is set
<cmeissl[m]>
in templat->bind for etna_resource_alloc, but screen->ro is NULL. But I am unsure if this is needed at all for making drmModeAddFB2 work or if gbm import should already be enough.
<emersion>
gbm_bo_get_handle is supposed to return a handle for the gbm_device's FD
<robclark>
so, if I had to take a guess, screen->ro is a hint that the etnaviv driver is created from drm/etnaviv rendernode and not the kmsro (display) device node
<emersion>
hm yeah it's weird
<robclark>
(also, austriancoder might have more experience with this)
<emersion>
these bugs with bad handle usually happen when screen->ro!=NULL
<emersion>
because in that case there are multiple DRM FDs and it's easy to mix these up
<robclark>
yeah.. this case sounds more straightforward ;-)
<robclark>
how does mesa get the device fd in the wayland case? Is it passed from the compositor?
<emersion>
no
<emersion>
the compositor sends the device dev_t
<emersion>
mesa uses drmGetDeviceFromDevId
<cmeissl[m]>
from what I can tell the fd is retrieved in dri2_initialize_wayland_drm, I stepped into it and it pointed to renderD128
<robclark>
ok.. I guess the compositor is sending the wrong dev-id?
<emersion>
why?
<robclark>
somewhere in the drm_helper/loader code it will use drmGetVersion() and then pick the driver (in this case either etnaviv directly or indirectly via kmsro) based on the reported driver name
<emersion>
ah, for scanout,. yeah that'd be the wrong device
<emersion>
which compositor?
<robclark>
if the reported name is etnaviv it will skip kmsro
kshishmanov has joined #dri-devel
<cmeissl[m]>
emersion: What I currently do is to send the renderD128 (etnaviv) as the main device in the tranche and card1 (imx-drm) in the scan-out tranche. Later the dmabuf is imported through gbm created from card1.
<cmeissl[m]>
Compositor is based on smithay (where I contribute regularly, specifically direct scan-out and dmabuf feedback).
<emersion>
yeah that's fine
jdavies has joined #dri-devel
<cmeissl[m]>
ok, good to know, I already tried all combinations because I suspected I do something wrong in the compositor with the tranche devices
jdavies is now known as Guest5858
kshishmanov has quit []
<robclark>
hmm, if the etnaviv render node is the one sent, I'm not sure how mesa would know how to create scanout capable surfaces
<cmeissl[m]>
right before DRM_IOCTL_MODE_ADDFB2 which prints "Failed to lookup GEM object" I can also see a call to DRM_IOCTL_PRIME_FD_TO_HANDLE returns -22
<emersion>
robclark: the wayland protocol sends different devices for scanout and not-scanout
<emersion>
maybe the driver doesn't check that DRM_IOCTL_PRIME_FD_TO_HANDLE succeeds?
<cmeissl[m]>
robclark: I am not 100% sure because I am already debugging that stuff for hours, but I am pretty sure I saw etnaviv as the reported name
<emersion>
which would explain the GEM lookup failure
<cmeissl[m]>
I thought it must have something to do with kmsro because the tranche scan-out flag results in PIPE_BIND_SCANOUT getting set for allocating the resource and etnaviv only uses that flag when screen->ro is not NULL
<cmeissl[m]>
I also tried to directly call drmPrimeFdToHandle and if IIRC that also returned an error
<cmeissl[m]>
I also tested with gstreamer waylandsink (decoding through v4l) and that works fine, the dmabuf is imported gets assigned to a overlay plane.
<robclark>
I guess the platform_wayland code in mesa needs to create the screen using the display dev instead of the render dev?
<cmeissl[m]>
I think I already tried to use card1 for the main device in the feedback, but I can try that again
<robclark>
I'm not familiar enough w/ the platform_wayland and wl proto stuff to know quite how this _expected_ to work.. but screen->ro==NULL is a big red flag that the fd the pipe-loader stuff uses to instantiate the screen is etnatviv rather than the display device
<cmeissl[m]>
I am actually not sure the code path that would set screen->ro gets called from the wayland egl platform, it does not look like that. So even if I send card1 it will also provide NULL for ro.
<bwidawsk>
robclark: but this is supposed to work today on freedreno for example
<bwidawsk>
Pretty sure daniels told me it does
<robclark>
cmeissl[m]: screen->ro is set in etna_screen_create() when called from kmsro_drm_screen_create()
<robclark>
bwidawsk: in almost all cases freedreno does not use kmsro... the exception is freescale imx5 things which have what (after acquisition from ati) became a2xx.. and I guess there aren't a whole lot of those things still in circulation
<robclark>
drm/msm covers both display and gpu in all other cases
<cmeissl[m]>
robclark: yeah, but I never see kmsro_drm_screen_create getting called, I always directly land in etna_drm_screen_create which always passed NULL for ro
Haaninjo has joined #dri-devel
<robclark>
right, which implies the screen is created from the render device, and not the display device
<cmeissl[m]>
I just tested it again with setting card1 as the main device, but that does not seem to make a difference. I still land in etna_drm_screen_create.
<cmeissl[m]>
Hm, dri2_initialize_wayland_drm doesn't seem to be happy with me sending card1 as the main device, because it is not a render node it falls back to wl_drm.
<robclark>
set a breakpoint in etna_drm_screen_create and step up the stack?
<cmeissl[m]>
Should wl_drm be initialized from card1 or render node? atm I initialize it from renderD128
<cmeissl[m]>
robclark: what shall I look at specifically? eglInitialize calls into dri2_initialize_wayland, which then lands in pipe_loader_create_screen, pipe_loader_create_screen_vk and finally in pipe_etnaviv_create_screen which calls etna_drm_screen_create
<robclark>
that is probably an emersion question.. but just looking at how kmsro and the pipe-loader stuff works, it looks like it is expected to be the display device.. that could be an xorg-ism, idk
<bluetail>
where do ALARM questions go ? (archlinuxarm)
<bwidawsk>
robclark: there's definitely something missing that seems to be in the glue. Looks like anholt_ also may be familiar
<cmeissl[m]>
robclark: I am not sure how to proceed, would it be best to open a issue in mesa and ping emersion and maybe austriancoder? The same code works on intel, amd, nvidia and vivante on i.mx8. (I did not test it myself, but someone reported that direct scan-out also worked with smithay on pine phone pro)
<robclark>
intel/amd/nv would all be single device providing scanout and render.. no idea how stuff works with vivante blob driver.. but yeah, open issue and cc emersion and maybe daniels.. I can only tell you why it isn't working.. but I can't tell you how it is supposed to work from wl standpoint
<cmarcelo>
is TGSI representation used by code outside mesa? I'm trying to understand if we have code that cares about TGSI_MEMBAR_ATOMIC_BUFFER individually (couldn't find evidence for this in mesa code), vs just handle MEMBAR ignoring the differences or assuming it is an SSBO.
<robclark>
cmarcelo, mostly no, except virgl.. which uses it in the guest->host interface (although possibly after some sanitizing?)
<cmarcelo>
robclark: is virgl code public? Ultimately I want to find out whether I need to plumb the atomic_counter barrier information down the pipes or not. (right now we just assume is a SSBO)
<robclark>
yeah, guest side is in mesa and host side is in virglrenderer
<cmarcelo>
cool. I'll take a look
<robclark>
I think we use (or at least support) ntt in the virgl case..
<robclark>
presumably if whatever happens on the core mesa side, we end up with same tgsi sent to host, then we are all good
<cmarcelo>
ok. virglrenderer will use that information to turn the TGSI_MEMBAR_ATOMIC_BUFFER back into GLSL memoryBarrierAtomicCounter().
<robclark>
right.. from an abi standpoint (ie. new guest on old host or visa versa) as long as we can ensure what mesa sends to the host is the same as before, everything should be happy
fab has quit [Quit: fab]
dviola has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
iive has joined #dri-devel
bgs has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
gouchi has quit [Remote host closed the connection]
kzd_ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
nukelet has quit [Read error: Connection reset by peer]