<tzimmermann>
with the reviews, this can finally go in
* javierm
looks
rkanwal has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
tomba has joined #dri-devel
anshuma1 has quit []
slattann has quit [Read error: Connection reset by peer]
tursulin has joined #dri-devel
<javierm>
tzimmermann: the missing patch reviewed. Sorry, I missed that you had a newer version of this patch-set and that a patch was still missing a r-b
<javierm>
tzimmermann: is there anything else that I reviewed an early version but fell through the cracks ?
<tzimmermann>
no worries
<tzimmermann>
i don't think so
<javierm>
tzimmermann: cool
<tzimmermann>
you're really doing the lions share of reviews of my patches. thanks a lot, javier
<javierm>
tzimmermann: you are welcome :)
jkrzyszt_ has joined #dri-devel
swalker__ has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest2804
lynxeye has joined #dri-devel
swalker__ has quit [Ping timeout: 480 seconds]
danylo has joined #dri-devel
nchery_ is now known as nchery
DemiMarie has joined #dri-devel
DemiMarie is now known as Guest2806
pcercuei has joined #dri-devel
heat has joined #dri-devel
Ristovski has quit [Ping timeout: 480 seconds]
kj_ has joined #dri-devel
mvlad has joined #dri-devel
kj has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
jekstrand[m] has joined #dri-devel
kj_ is now known as kj
rkanwal has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
fahien has joined #dri-devel
znullptr[m] has joined #dri-devel
DrNick has joined #dri-devel
DrNick is now known as Guest2808
kem has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
khfeng has quit [Remote host closed the connection]
khfeng has joined #dri-devel
kem has joined #dri-devel
chipxxx has joined #dri-devel
gagallo7[m] has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
fahien has quit [Quit: fahien]
fahien has joined #dri-devel
YaLTeR[m] has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
<LaserEyess>
emersion: this is eDP, I know HDMI won't work, although apparently some TVs allow it on HDMI 2.1 if they support freesync over HDMI, not quite sure how that works
<LaserEyess>
interestingly enoguh, if I look at the possible modesets I do see the lower refresh rate bound at 48 Hz
<LaserEyess>
and I can switch to it
<LaserEyess>
I don't know how the kernel treats eDP vs DP but perhaps the former isn't whitelisted for vrr support
Ristovski has joined #dri-devel
kusma has joined #dri-devel
Weiss-Fder[m] has joined #dri-devel
<daniels>
javierm: ooi if you pull weston main as of now, do you see foot showing up?
sdutt has joined #dri-devel
<illwieckz>
an idea just popped into my mind, since rusticl can work on zink on vulkan because zink is a gallium driver, can nine work on zink on vulkan the same way?
<zmike>
stay tuned
<illwieckz>
I know there are now other alternatives implementing dx, even doing it directly in vulkan, but I'm curious about it
<illwieckz>
héhé
fxkamd has joined #dri-devel
dcbaker has joined #dri-devel
dakr has quit [Read error: Connection reset by peer]
dakr has joined #dri-devel
zehortigoza has joined #dri-devel
r[m] has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
chipxxx has quit [Read error: Connection reset by peer]
<dcz_>
so I render some stuff to a surface using OpenGL. Afterwards I want to read out that surface using mmap. How do I force OpenGL to synchronize the results of the rendering?
gdevi has joined #dri-devel
<dcz_>
I accidentally had it working only because I cleaned up all OpenGL resources before the readout, but that's not efficient if I want to render multiple frames
fab has quit [Quit: fab]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
rasterman has quit [Ping timeout: 480 seconds]
<emersion>
dcz_: how do you mmap?
<emersion>
raw mmap, GBM, GL PBO…?
<dcz_>
GBM
<emersion>
that should synchronize as necessary
<emersion>
note, accessing mmap buffers can be slow
KunalAgarwal[m][m] has joined #dri-devel
<emersion>
the recommended way is to access bytes sequentially one time and be done with it
<dcz_>
I first create the buffer, then import to OpenGL, then render to it with a shader, then read out nothing
<emersion>
do you glFlush()
<emersion>
?
<dcz_>
oh, that's something I was missing, thanks :)
<emersion>
glFlush() creates an implicit sync barrier, basically saying "i'm done with the rendering commands for now"
<emersion>
it does not wait for the commands to complete on the GPU
<emersion>
but GBM mmap will wait (in a blocking fashion)
rasterman has joined #dri-devel
<vsyrjala>
did we have a reason drm_mode_config_cleanup() doesn't nuke the private objs? i have a feeling someone even had a patch to do that...
MajorBiscuit has joined #dri-devel
Leopold_ has quit []
Haaninjo has joined #dri-devel
<dcz_>
emersion: newest version of glium has a barrier that I can call and it works. It's ctxt.gl.MemoryBarrier(gl::FRAMEBUFFER_BARRIER_BIT)
<emersion>
hm, i am not sure this is enough for the purposes of implicit sync
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
<emersion>
the spec only talks about shader accesses
<emersion>
(there is an official khronos website, but this one is more comfortable to use)
vup has quit [Ping timeout: 480 seconds]
<dcz_>
thanks. That's a FIXME
<jfalempe>
tzimmermann, with one correction, Gnome/Wayland works well on Aspeed BMC.
<javierm>
daniels: I'll try that tomorrow since don't have access now to my laptop where I had that VM for testing
kts has joined #dri-devel
<dcz_>
"glFlush can return at any time. It does not wait until the execution of all previously issued GL commands is complete." - wut? I can't figure it out what this synchronizes
<zmike>
it's not guaranteed to synchronize anything
<karolherbst>
dcz_: to tell the GPU to start doing stuff
<zmike>
maybe start doing stuff*
<karolherbst>
***
<javierm>
jfalempe, tzimmermann: for machines with an aspeed bmc, then the system framebuffer when booting linux is provided by the BMC and used by the ast driver or ?
<javierm>
kind of what efifb does for EFI and vesafb for legacy BIOS/VESA ?
<dcz_>
okay, now I get it
<agd5f>
LaserEyess, IIRC, some eDP panels advertise HDMI VRR support rather than DP VRR support so I'm not sure the driver picks those up properly.
<karolherbst>
glFinish is doing the hard sync thing, but people are generally not supposed to use that
<dcz_>
yeah, glFinish is too heavy of a hammer
<jfalempe>
javierm, in this case the uefi setup the framebuffer, and efifb is using it. BMC is able to get the video framebuffer and send it on its web server.
<jfalempe>
with BMC you can see the whole boot process (like going in uefi menu, grub, plymouth, and gnome)
<javierm>
jfalempe: so the same aperture is mapped to both efifb and ast ?
<jfalempe>
yes
<tzimmermann>
javierm, the BMC monitors the chip and it's video memory. it doesn't need additional linux support AFAIK
<tzimmermann>
IIRC the aspeed chip is an arm cpu converted to display chip. integrating this with BMC functionality seems logical
<javierm>
tzimmermann: yes, but then I guess this only works because the ast driver doesn't call to request_mem_region() ?
<tzimmermann>
the efifb aperture is in the ast's video memory (as it's with other chips)
<javierm>
otherwise it would fail right ?
<tzimmermann>
i don't understand
<tzimmermann>
the BMC is a separate arm chip. it monitors the graphics registers
<dcz_>
glFlush also works
<tzimmermann>
at least that's my understanding of the thing
<javierm>
tzimmermann: Ok, but the PCI BAR is different then?
<tzimmermann>
the x86's bios/uefi initializes the firmware graphics mode.
<javierm>
for let's say simpledrm using the display controller and ast using the aspeed bmc dp?
kem has joined #dri-devel
<tzimmermann>
the BMC just observes the state of the graphics registers
<jfalempe>
ast calls drm_aperture_remove_conflicting_framebuffers() to remove efifb and take its place.
<javierm>
jfalempe: but that would also kick out simpledrm then, right ?
<tzimmermann>
right
<javierm>
tzimmermann: Ok. That's what I was trying to say then
<javierm>
they are mutually exclusive then, you either use efifb or ast
<tzimmermann>
exactly
<javierm>
tzimmermann: got it. Makes sense
<javierm>
and now understand the bug, the user was using the proprietary nvidia driver and so loading ast would kick out the efifb
<javierm>
known issue then and nothing we can do about
fab has joined #dri-devel
<dcz_>
actually, glFlush works, but only partially: the mmap starts off reading uninitialized data
<dcz_>
I've slapped glFinish on it, so that it can become somebody else's problem :)
<tzimmermann>
javierm, this url that you posted? what is he trying to do?
JohnnyonFlame has joined #dri-devel
<javierm>
tzimmermann: is trying to get VT working with a proprietary nvidia driver
<javierm>
tzimmermann: nvidia + efifb works but no nvidia + ast
<pq>
dcz_, do you gbm_bo_mmap() *after* calling glFlush()?
<tzimmermann>
what?
Lucretia has quit []
<tzimmermann>
if efifb runs on nvida-hw, ast shouldn't unplug it.
<tzimmermann>
if efifb runs on ast-hw, why does it affect nvidia?
<javierm>
tzimmermann: but you just said that ast and efifb would share the same aperture and so drm_aperture_remove_conflicting_framebuffers() would kick out the other ?
<tzimmermann>
i just saw that url now. the user has nvidia *and* ast hardware in the same system?
<javierm>
tzimmermann: it seems so, yes
<tzimmermann>
i have ast + intel in the same system. it works for me
<dcz_>
pq: I do gbm_bo_get_fd *before* glFlush()
<javierm>
tzimmermann: yes, but intel does the correct thing. It exposes an emulated fbdev device
<javierm>
tzimmermann: nvidia relies on efifb for that
<pq>
dcz_, if you don't, I think you should. And unmap when you're done, so that on the next time on the same buffer, you can gbm_bo_map() after glFlush again.
<javierm>
tzimmermann: so fbcon can't bind to a fbdev device, which is the case if ast kicks out efifb
<pq>
dcz_, not get_fd, but gbm_bo_map()
<pq>
dcz_, or are you saying you are using gbm_bo_get_fd() and then regular mmap() on that?
<dcz_>
yes, that's what I do
<pq>
dcz_, ok, that explains why glFlush is not enough.
Lucretia has joined #dri-devel
<dcz_>
how bad of a misuse is this :P?
<pq>
I believe regular mmap() does not know to wait for the GPU to finish. gbm_bo_map() should know, I think.
<tzimmermann>
javierm, indeed. what i don't get: if efifb runs on nvidia-hw, ast should not kick it out. if efifb runs on ast-hw, nvidia should not work in either case
<pq>
dcz_, regular mmap() is the lowest possible level of API, so you get to handle everything from format modifier to synchronization yourself, and it can be painfully slow too.
<pq>
slow to access
* tzimmermann
decides that the problem is in nvidia's driver
<pq>
dcz_, gbm_bo_map() takes most of that pain off your hands.
<javierm>
tzimmermann: yeah, not really familiar with the HW hierarchy of machines with ast and I don't even understand how nvidia + efifb could work together tbh
<dcz_>
hm, I'm not sure if I can do much, libcamera's API is based on mmappable FDs
<javierm>
tzimmermann: but yes, their problem in any case
<pq>
dcz_, you can import an fd to GBM to get a gbm_bo.
vup has joined #dri-devel
<dcz_>
I already have a gbm bo, but I have to provide a fd
<pq>
umm, so?
<pq>
oh, is it the other one who will then be calling mmap() on that fd?
<tzimmermann>
javierm, i guess that the nvidia driver doesn't look at it's internal hardware state to detect the console. instead it looks at efifb's internal state to detect the console. apparently even if efifb doesn't run on the nvidia device
<dcz_>
yes
<dcz_>
I provide the buffers
<pq>
dcz_, ouch.
<dcz_>
I may still be wrong...
<tzimmermann>
otherwise, none of this makes sense
Guest2806 is now known as DemiMarie
<javierm>
tzimmermann: yeah, something like that. But now at least the issue is clear to me, I didn't understand the relation between efifb and ast before
<pq>
dcz_, the thing is, not all fds are equal. A file fd differs from dmabuf fd in many obvious ways, but also in non-obvious ways.
<pq>
dcz_, like IIRC there is this ioctl you must bracket your mmapped access with, to make regular mmap() work.
<pq>
that ioctl takes care of flushing the necessary caches, so that you see good data
<pq>
and it's specific to dmabuf fd, AFAIK
<pq>
dcz_, good luck, I need to go now. :-)
<pq>
(glFinish is not guaranteed enough, AFAIU)
<dcz_>
pq: thanks! I'll ask libcamera devs what the API is
srslypascal is now known as Guest2824
srslypascal has joined #dri-devel
vup has quit []
vup has joined #dri-devel
fahien has joined #dri-devel
fahien has quit []
Guest2824 has quit [Ping timeout: 480 seconds]
undvasistas[m] has joined #dri-devel
<kbingham>
dcz_, If we need to be using OpenGL buffers and calls, we can make a FrameBufferAllocator in libcamera that uses OpenGL to allocate in the back end I expect.
<kbingham>
Or if there are explicit calls that need to be made to be able to synchronise the cache, they could be added somewhere.
<kbingham>
I'm not sure I fully understand the whole issue yet though.
<dcz_>
kbingham: the buffers coming from the allocator are used only to receive data from the video device; the buffers the application ends up receiving are OpenGL buffers
<kbingham>
Ok - so buffers allocated with V4L2 (libcamera) are used to capture the image from the sensor, these are passed to OpenGL who then write to buffers allocated by OpenGL, which are returned to your soft-isp component?
Duke`` has joined #dri-devel
<dcz_>
buffers from libcamera are used to capture the image from the sensor. The soft ISP allocates some buffers using GBM, and makes them the targets of OpenGL operations (with libcamera buffers on the input side). Finally, the GBM buffers are submitted to the consumer
<dcz_>
a special buffer allocator would do the trick as long as the consumer knows how to access the new buffer type
<kbingham>
In libcamera, the application is responsible for providing the 'output' buffers that it receives, (it might pass in buffers that are going to be directly rendered to the screen) ... so I think we need to look at how that's being handled indeed.
tzimmermann has quit [Quit: Leaving]
vliaskov_ has quit [Remote host closed the connection]
<kbingham>
And if there's any synchronisation requried, indeed it should be handled by the soft-isp component to ensure when the buffer is completed, and passed to the application it can be used. But the pain point there is - if the application is simply going to pass it directly to display, we don't want to mmap it ... or wait for cache handling - as that would be wasted effort. So ... it seems tricky to know where to put these sync calls. (And
<kbingham>
I'm not sure what ioctl it is yet, pq - did you leave already?)
<kbingham>
If it's a generic ioctl that operates on a dmabuf, we could add it to libcamera I expect. Perhaps it needs to be called conditionally based on if the application actually wants to read the buffer with the CPU - or if it doesn't care then it wouldn't get called.
vup has quit [Ping timeout: 480 seconds]
<emersion>
kbingham: DMA_BUF_IOCTL_SYNC
<kbingham>
Thanks, was googling for that ;-)
<emersion>
kbingham: mind, if the buffer is not forced to have a linear layout, then your mmap will contain data you can't interpret
<emersion>
GBM will convert the layout for you in gbm_bo_map()
<kbingham>
emersion, Define linear layout. Do you mean a pixelformat that is non linear? or you mean the buffers are 'scatter gather' ?
<kbingham>
(actually, mmap would solve scatter gather / non-contigious memory)
<emersion>
i mean that by default buffers will have vendor-specific tiling
<kbingham>
emersion, I don't think that's an issue here.
<kbingham>
Or ... at least not at this point in the pipelien.
<emersion>
if you use plain mmap on a buffer allocated via e.g. GL, then it won't work, even with the sync IOCTLs
<kbingham>
dcz_, is using OpenGL to convert a captured image from a camera sensor, to a new pixelformat/(with operations like debayering/demosaicing) so that code should be in control of the buffer layout. It shoudln't be tiled.
<kbingham>
(Unless, there's a GPU specific tiling occuring that I'm not yet aware of, and you're not talking about tiling used for display buffers)
<dcz_>
in practice I'm using linear buffers
<kbingham>
phew :)
<dcz_>
GBM has a flag to enforce that
<emersion>
okay, just making sure you're aware
<emersion>
and yeah, be careful with the access patterns of the mmap'ed region
<emersion>
usually the only reasonable thing to do is to memcpy the thing to CPU memory
<kbingham>
I'm quite sure we don't want any memcpys ;-)
<emersion>
what are you doing once the buffer is mmap'ed?
heat has quit [Read error: Connection reset by peer]
<emersion>
by "memcpy" i mean sequential read of each byte
heat has joined #dri-devel
<kbingham>
emersion, ... I need to dig to be sure I'm not missing something... why ?
<kbingham>
(I feel like I'm missing something)
<emersion>
kbingham: non-sequential accesses can be very slow
<kbingham>
Ok - so just about cache throughput. That's fine.
<emersion>
iirc it's uncached
<kbingham>
If it's uncached what is the DMA_BUF_IOCTL_SYNC call doing ? (I can dig into the kernel to find that out too though)
<emersion>
although i don't remember the details -- MrCooper does, but is away on holidays
<kbingham>
"The synchronization provided via DMA_BUF_IOCTL_SYNC only provides cache coherency"
ybogdano has joined #dri-devel
vup has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
airlied: can we remove ./src/gallium/drivers/llvmpipe/lp_bld_alpha.c and just unset PIPE_CAP_ALPHA_TEST and let mesa/st lower it in NIR?
<alyssa>
given that it's in the case anyway
<alyssa>
I'd write the patch but I don't have the hardware-- shoot
zzoon_holidays_until_3rd_Oct[m has joined #dri-devel
mbrost has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
chipxxx has joined #dri-devel
Newbyte has joined #dri-devel
Guest2804 has quit [Remote host closed the connection]
Akari has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
Major_Biscuit has quit [Ping timeout: 480 seconds]
<karolherbst>
ahhhhhhhhhhhhhhhhhhhhhhhhhh why are compilers :(
<HdkR>
Potential divide by zero so it disables the fault?
<karolherbst>
it sets the PE flag
<karolherbst>
but it doesn't revert the change
<karolherbst>
divss is used
<HdkR>
haha
<HdkR>
Of course it would :|
<karolherbst>
the fuck
<karolherbst>
this is blocking CL conformance...
<HdkR>
idiv not even a once?
ngcortes has joined #dri-devel
<karolherbst>
(ノಠ益ಠ)ノ彡┻━┻
<alyssa>
I don't even want to ask what that file is for
<alyssa>
".
<alyssa>
"L1-normalize a vector of L3 partition weights."
<alyssa>
Someone just really wanted to confuse people (:
<karolherbst>
it's called when creating the iris screen
<alyssa>
Becuase the first L1/L3 is different than the second L1/L3, I have to assume (:
<karolherbst>
but _why_ does it mess with mscsr :(
<karolherbst>
I will create the most stupid MR fixing it in the most stupid way I can think of
<HdkR>
Because it wants to abuse divss obviously
<HdkR>
inline asm using DIV
<karolherbst>
worse
<HdkR>
save and restore mxcsr? :D
<karolherbst>
yep
<karolherbst>
more fails but it might be stupid stuff being equally stupid
<karolherbst>
ahhh... who else is setting it :D
<karolherbst>
I think I'll save/restore in rusticl...
<karolherbst>
but that's pain
michael5050[m] has joined #dri-devel
<karolherbst>
uhhhh
<karolherbst>
there are other places it gets set
aravind has quit [Ping timeout: 480 seconds]
<vsyrjala>
mxcsr looks fun. both callee and caller saved
<HdkR>
More like MXCSR is a hot mess
<HdkR>
Sprinkle some FPSCR in there from the ARM side and we have a hodgepodge nightmare
<karolherbst>
why is x86...
<HdkR>
Good news is that on the ARMv8 side, no consumer hardware supports FP exceptions except for Macbooks. But that means compilers won't touch that shit :D
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
<karolherbst>
:D
<karolherbst>
sane
Jean[m]1 has joined #dri-devel
<karolherbst>
WTF
<karolherbst>
llroundf as well
mbrost has quit [Ping timeout: 480 seconds]
<HdkR>
Wack a mole time
<karolherbst>
we use it when packing pixels :)
<karolherbst>
:) :) :)
<karolherbst>
🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
<karolherbst>
cvttss2si
<karolherbst>
why are compilers...
halfline[m] has joined #dri-devel
<karolherbst>
I even compile with O0
<karolherbst>
it makes no sense
<vsyrjala>
oh right, that mxcsr was the thing arch/x86 folks broke on 32bit a while back. my machine booted but network didn't work due to dhcpcd exploding
<karolherbst>
clang is doing the same though
<karolherbst>
uhhh....
<karolherbst>
vsyrjala: remember what broke it?
<vsyrjala>
kernel screwed up the save/restore
<karolherbst>
uhhh
<karolherbst>
I am on 5.19.10...
<karolherbst>
let me upgrade and hope it fixes it
<vsyrjala>
apparently a while back is one year. i could have sworn it happend no more than four months ago
<karolherbst>
maybe somebody messed it up again :)
<vsyrjala>
anything using sse would likely blow up
jkrzyszt_ has quit [Ping timeout: 480 seconds]
<karolherbst>
maybe it's less broken and it only messes up a little bit
<vsyrjala>
which i guess would be almost everything on 64bit, even on binary distros
heat_ has joined #dri-devel
<karolherbst>
right.. I usually test on 5.18...
<karolherbst>
*sigh*
heat has quit [Read error: No route to host]
<vsyrjala>
anyways, sounds to me like you're perhaps just violating the abi by not saving/restoring enough of mxcsr
<karolherbst>
I am not doing anything to it
<karolherbst>
a C division causes this :/
<vsyrjala>
but you're doing some raw sse somewhere else no?
<karolherbst>
nope
<danvet>
karolherbst, yeah you're tweets are seriously sending me into despair
<danvet>
x86 abi can't be that bad
<karolherbst>
danvet: you saw the code, right?
<karolherbst>
tell me what I am doing wrong here :D
<danvet>
not enough hard liquor here for that
<vsyrjala>
is rust violating the abi?
<danvet>
and yes I'm trying to get rid of that memory
<karolherbst>
it's not rust doing it
<karolherbst>
it's C code
<karolherbst>
the pixel packing code also triggers it
<vsyrjala>
you know that nothing else incorrectly screwed with mxcsr before that?
<karolherbst>
yep
<karolherbst>
I checked $mxcsr before and after
<karolherbst>
even set watchpoints (which are slow as hell)
<karolherbst>
executing divss seems to flip the PE bit in mxcsr
<karolherbst>
or well.. something there
genpaku has quit [Remote host closed the connection]
<HdkR>
karolherbst: Flipping a bit is fine, flipping the exception bit mask, not so fine
<karolherbst>
maybe..
<karolherbst>
but the code is doing the wrong thing either way
lynxeye has quit [Quit: Leaving.]
ngcortes_ has joined #dri-devel
ngcortes_ has quit [Read error: Connection reset by peer]
<vsyrjala>
i don't see what's wrong with it. callee is allowed to clobber the status bits afaics
ngcortes has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah.. it would make sense
<karolherbst>
I just saw some tests in the CTS where it calculates the wrong result, but I also get cases where it's the other way around
RAOF has joined #dri-devel
masush5[m] has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<yang>
So, I am trying to solve the freezing issue on the computer. In my case being booted with Debian's bookworm and buster's 4.19 kernel doesn't freeze my machine, when using bookworm's or any kernel after 4.19 is freezing the machine.
<yang>
I would like to point again to the issue #2215
<HdkR>
illwieckz: Likely it could be added to `src/vulkan/wsi/meson.build` where it is using the dependency, or in `src/gallium/frontends/lavapipe/meson.build` where it is using the wsi dependency
<illwieckz>
yes
<HdkR>
Seems logical to set the dependency with the library that is actually using udev
<HdkR>
Because it's linking `idep_vulkan_wsi` which doesn't have the libraries dependencies on it
<HdkR>
Which is at the bottom of that file
<glehmann>
pendingchaos: thanks, that's way simpler than what I thought I had to do
<dcbaker>
illwieckz: because meson doesn't propogate linked dependencies to avoid overlinking. I think the right solution is to put in udev in the `idep_vulkan_wsi`
<HdkR>
\o/
<illwieckz>
so your PR
<karolherbst>
that "Half Float IMM" is also quite helpful
<illwieckz>
I think it's a good idea to reference libudev in the same file anyway
gouchi has joined #dri-devel
<illwieckz>
HdkR, I closed my MR in favor of yours.
<HdkR>
coolio
<dcbaker>
HdkR: That looks good to me, I'm just trying to decide whether we need that for 22.1