ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
LexSfX has joined #zink
LexSfX has quit []
LexSfX has joined #zink
LexSfX has quit [Ping timeout: 480 seconds]
LexSfX has joined #zink
LexSfX has quit []
LexSfX has joined #zink
lodi has joined #zink
lodi has quit []
Soroush has joined #zink
eukara has quit []
eukara has joined #zink
<zmike> bnieuwenhuizen: this might be one for you: a new issue with zink now that wsi is hooked up is I have no drm fd, which breaks gallium when I need to be able to return a drm handle
<zmike> it seems somewhat inconvenient to get a drm fd myself though
<bnieuwenhuizen> ?
<zmike> is there a convenient way to get a drm fd?
<bnieuwenhuizen> isn't that going to get messy for nvidia?
<zmike> probably, but I can be selective when I do it
<airlied> what interfaces need it?
<zmike> dmabuf
<zmike> ext_image_dma_buf_import-export-tex crashes because of it
<zmike> used to pass
<bnieuwenhuizen> might be worth looking at VK_EXT_physical_device_drm ?
<zmike> 🤔
<bnieuwenhuizen> doesn't get you the fd itself, just the major/minor
<bnieuwenhuizen> but at that point you can likely poke libdrm
<zmike> this might do
<zmike> thanks
<airlied> zmike: that drmPrimeFDToHandle has always been suspect
<zmike> shrug
<zmike> it works
<airlied> and a layering violation, just what it should be I've no idea
<airlied> well now it doesn't
<zmike> :D
<airlied> so maybe we could fix it so it works properly
<zmike> that's the goal
<airlied> but it may need a vk ext
<zmike> time enough for that when I finish my second dmabuf implementation of the day
<bnieuwenhuizen> which drmPrimeFDToHandle are we talking about?
<airlied> the one in zink
<airlied> I think it's the main user of the drm fd
<zmike> the only one
<bnieuwenhuizen> sigh, the entire thing of returning KMS handles is very messy in the first place
<bnieuwenhuizen> like the main user for that would be KMS
<bnieuwenhuizen> and for that to make sense the KMS fd needs to be the same as the driver fd
<bnieuwenhuizen> and at that point the app has to be opening gbm with the known kms fd AFAIU
<bnieuwenhuizen> at which point I doubt you'd need the drm fd from the driver?
<zmike> I'm just trying to match up with the gallium apis, which expect a drm handle from that type
<bnieuwenhuizen> in all cases where that handle is useful I think you should've gotten a drm fd on screen/device creation?
* bnieuwenhuizen checks gallium
<zmike> nope, not with kopper
<ajax> kopper means the device creation api is vulkan not gbm
<bnieuwenhuizen> why would an app ever request a kms handle in that case?
<bnieuwenhuizen> like AFAIU literally the only point for it is kms based compositors(or xserver I guess)
<bnieuwenhuizen> and compositors would use gbm to get a GL device, no?
<zmike> that's just how gallium api works
<bnieuwenhuizen> ?
<zmike> most of dri2 frontend uses WINSYS_HANDLE_TYPE_KMS
<zmike> so it's drm handles
<bnieuwenhuizen> doesn't kopper replace that?
<zmike> no, it reuses a lot of it
<bnieuwenhuizen> okay, now I'm totally lost, maybe I should actually browse some code
<zmike> you can run that piglit test I cited on zink right now
<zmike> and it will crash
<bnieuwenhuizen> that test just needs FDs, not handles
<zmike> 🤔
<bnieuwenhuizen> IMO better to refactor the dri2 frontend not to need handles for that
<zmike> definitely sounds like a job for somebody
* airlied wants everyone to sing the eminem lyrics, this looks like a job for me...
<bnieuwenhuizen> ah, I hate this interface, it requests a KMS handle if it only needs offset/stride
* airlied is not getting nersniped on a friday
<bnieuwenhuizen> incline to add a HANLDE_NONE
<bnieuwenhuizen> zmike: majestic hack: if you have no drm_fd, return 0
<bnieuwenhuizen> (untested)
<zmike> bnieuwenhuizen: where?
<bnieuwenhuizen> whenever a KMS handle is requested
<zmike> hm
<bnieuwenhuizen> like if you look at dri2_query_image_by_resource_handle it is clear nobody actually cares about the handle
<zmike> ...
<zmike> how are you this smart
<bnieuwenhuizen> (except for __DRI_IMAGE_ATTRIB_HANDLE but that is the special thing when you should have a drm_fd)
<zmike> hm but now it just crashes in a different way
<zmike> is this my fault
<Sachiel> anything isn't?
<zmike> tough but fair
<ajax> use -1 instead
<ajax> 0 is a valid fd
* airlied loved the time I had a -1 fd and passed it to kill(2)
<airlied> took me a while to figure that out
<bnieuwenhuizen> well, if my hypothesis that nothing uses it is wrong, I think it isn't such a great hack anymore, so if -1 fixes things ...
<airlied> it's like why did all my processes get logged out
<bnieuwenhuizen> what does -1 do there?
<bnieuwenhuizen> oh
<zmike> there's no need to return a value
<zmike> it has a bool
<zmike> so false is fine
<bnieuwenhuizen> zmike: uh what?
<bnieuwenhuizen> with return I fully meant to set the handle to 0, not to change the return value
<zmike> oh
<zmike> well this works too
<zmike> somehow
<zmike> bnieuwenhuizen: does passing VkExportMemoryAllocateInfo for fd export have perf implications?
<zmike> or only when the export occurs
<bnieuwenhuizen> some CPU overhead potentially on every submit
<zmike> :/
<zmike> doesn't seem like I can avoid it
<bnieuwenhuizen> having 100-200 is par for the course though
<zmike> huh lavapipe now passing more dmabuf piglits than anv