ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
YuGiOhJCJ has joined #dri-devel
zamundaaa[m] has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
khfeng has joined #dri-devel
vup has quit []
vup has joined #dri-devel
ybogdano has joined #dri-devel
Leopold has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
egalli has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #dri-devel
jernej has quit [Remote host closed the connection]
jernej has joined #dri-devel
rgallaispou has joined #dri-devel
zamundaaa[m] has quit [Ping timeout: 480 seconds]
egalli has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Ping timeout: 480 seconds]
robertmader[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
tleydxdy has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
AlexisHernndezGuzmn[m] has joined #dri-devel
vsyrjala_ has joined #dri-devel
vsyrjala has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
T_UNIX has joined #dri-devel
Sumera[m] has joined #dri-devel
mhenning has quit [Quit: mhenning]
mbrost has quit [Read error: Connection reset by peer]
lemonzest has joined #dri-devel
ngcortes has quit [Quit: Leaving]
kem has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
kem has joined #dri-devel
bmodem has joined #dri-devel
anshuma1 has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
ella-0_ has joined #dri-devel
kem has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
ella-0 has quit [Read error: Connection reset by peer]
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
fxkamd has quit []
bmodem has quit []
bmodem1 has joined #dri-devel
eyearesee has joined #dri-devel
Duke`` has joined #dri-devel
bmodem1 has quit []
aravind has joined #dri-devel
kts has joined #dri-devel
khfeng has quit [Quit: Konversation terminated!]
khfeng has joined #dri-devel
nchery has quit [Remote host closed the connection]
khfeng has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
Duggan has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
dcz_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<emersion> LaserEyess: i think there were some concerns about patents with HDMI…
nchery_ has joined #dri-devel
<emersion> DP should work
nchery has quit [Ping timeout: 480 seconds]
Vin[m] has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
bgs has quit [Remote host closed the connection]
heftig has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
danvet has joined #dri-devel
slattann has quit [Quit: Leaving.]
yshui` has joined #dri-devel
aura[m] has joined #dri-devel
khfeng has joined #dri-devel
tzimmermann has joined #dri-devel
GeorgesStavracasfeaneron[m] has joined #dri-devel
kts has quit [Quit: Leaving]
frieder has joined #dri-devel
frieder_ has joined #dri-devel
frieder has quit [Read error: Connection reset by peer]
frieder_ has quit []
fab has joined #dri-devel
frieder has joined #dri-devel
kunal_10185[m] has joined #dri-devel
rasterman has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
MajorBiscuit has joined #dri-devel
vsyrjala_ is now known as vsyrjala
slattann has joined #dri-devel
Ristovski has quit [Ping timeout: 482 seconds]
anshuma1 has quit []
kts has joined #dri-devel
anshuma1 has joined #dri-devel
<javierm> tzimmermann: do you want me to review the rest of your "[PATCH 0/8] drm/ast: Convert ast driver to SHMEM" series?
<javierm> tzimmermann: I believe jfalempe would do that?
<javierm> I just reviewed patch #3 because I remember we talked about that before
<tzimmermann> javierm, thanks for that review. i'd see if jocelyn wants to review the others. she's hardware to test
Ristovski has joined #dri-devel
<javierm> tzimmermann: perfect
<jfalempe> javierm, yes I'm currently building a kernel to test, the server was off yesterday, so I will only test today.
<javierm> jfalempe: awesome!
<tzimmermann> jfalempe, great, thanks
<tzimmermann> javierm, i would appreciate a review of the ofdrm patcheset. there's now one more patch i added for big-endian systems. https://lore.kernel.org/dri-devel/20220928105010.18880-1-tzimmermann@suse.de/
<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]
heat has joined #dri-devel
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
Leopold has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
devilhorns has joined #dri-devel
Wallbraker[m] has joined #dri-devel
Leopold has quit []
Anson[m] has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
sumits has left #dri-devel [Leaving]
sumits has joined #dri-devel
fahien has joined #dri-devel
kts has quit [Quit: Leaving]
enick_11 has joined #dri-devel
reactormonk[m] has joined #dri-devel
sven has quit [Quit: ZNC 1.8.2 - https://znc.in]
sven has joined #dri-devel
fahien has quit [Quit: fahien]
MajorBiscuit has quit [Quit: WeeChat 3.5]
x512[m] has joined #dri-devel
devilhorns has quit []
jasuarez has joined #dri-devel
<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
<dcz_> what's the spec for that?
<emersion> just GL
<dcz_> I was searching by famebuffer_barrier
<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
<javierm> jfalempe, tzimmermann: can you please enlighten me with https://bbs.archlinux.org/viewtopic.php?id=279971 ?
<dcz_> what is its purpose?
kem has quit [Ping timeout: 480 seconds]
<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 :(
<karolherbst> _why_
<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]
genpaku has joined #dri-devel
<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
<yang> I dunno if it's related
alyssa has left #dri-devel [#dri-devel]
<yang> it keeps freezing with every new kernel
Xogium has joined #dri-devel
<yang> latest issue regarding i915 is this, when updating the machine https://paste.debian.net/1256709/
<yang> Could it be related to dual monitor setup? I have one on HDMI-out and another on DVI-out...
kunal10710[m] has joined #dri-devel
Leopold has joined #dri-devel
Akari has joined #dri-devel
<karolherbst> ehhh... okay.. one bug is nextafter being broken for fp16
chipxxx has quit [Read error: Connection reset by peer]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<HdkR> Confirmed with a COVID quick test today. No COVID from XDC, woop woop
<karolherbst> \o/
heat_ has quit [Read error: No route to host]
heat has joined #dri-devel
robertfoss[m] has joined #dri-devel
Jeremy_Rand_Talos_ has joined #dri-devel
rsjw has joined #dri-devel
naheemsays[m] has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
pushqrdx[m] has joined #dri-devel
<HdkR> Is it just me or is lavapipe failing to pull in vulkan_wsi libudev dependencies and failing to compile?
<zmike> someone recently claimed to have this issue and it turned out to be a user error
<zmike> or something like that
<HdkR> Wouldn't be too unexpected
<airlied> HdkR: arch?
<HdkR> airlied: x86-64 here
<airlied> i meant atch linux?
<HdkR> an "everything" driver
<HdkR> oh no
<HdkR> Ubuntu
<HdkR> 22.04
lemonzest has quit [Quit: WeeChat 3.6]
<airlied> last report was i think systemd bug
<HdkR> That's...odd
<HdkR> It's just missing the libudev dependency in the link as far as I can tell
<HdkR> lol what. Does it though?
<HdkR> Maybe they just uninstalled libudev-dev or w/e arch has and it continued happily
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
<HdkR> Since I don't see any other way lavapipe would get the necessary udev dependency
<airlied> yeah its just wierd it is popping up now
<airlied> unless its a new dep
<HdkR> Doesn't seem to be new
Strit[m] has joined #dri-devel
fab has quit [Quit: fab]
<HdkR> Could be one of the other dependencies dropped their udev usage
<HdkR> yes
<HdkR> That's the case, libdrm had udev and dropped it
<HdkR> So it needs to be added to that idep case
<airlied> ah makes sense then
<HdkR> That was back in 2018 that got removed though... Maybe one of the xcb libraries
<glehmann> I have a nir_if and a nir_instr, what is the easiest way to check if the instr is in the block directly before the if?
<pendingchaos> &instr->block->cf_node == nir_cf_node_prev(&nif->cf_node)
<karolherbst> uhhh...
<karolherbst> intel uses flt32 for a fp16 comparision...
<karolherbst> that explains a lot
<HdkR> Well it doesn't natively support FP16 until AVX512
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<karolherbst> meant on the GPU side
<HdkR> ah
<illwieckz> <zmike> someone recently claimed to have this issue and it turned out to be a user error
Jeremy_Rand_Talos_ has joined #dri-devel
heat has quit [Read error: No route to host]
heat_ has joined #dri-devel
<illwieckz> my user error was to believe the issues wasn't there anymore
<zmike> yeah, see?
<illwieckz> the issue is still there
<karolherbst> mhhh
<illwieckz> though, it may be an issue elsewhere than in mesa, like meson
<karolherbst> we do have lower_fp16, but that obviously doesn't handle rtp or rtn
mvlad has quit [Remote host closed the connection]
ppascher has quit [Quit: Gateway shutdown]
<illwieckz> it looks like we are more than one people trying to add libudev there or there
<zmike> paging dcbaker
<karolherbst> ehh wait
<karolherbst> flt16 just means 16 bit result
<HdkR> illwieckz: MR #19037 opened
<dcbaker> zmike: this is dcbaker, over
<zmike> dcbaker: we've got a situation with the build system, over
<dcbaker> zmike: sounds bad, over
<zmike> dcbaker: not too bad, over
<ccr> Airplane!
Haaninjo has quit [Quit: Ex-Chat]
<dcbaker> what's your vector, victor?
frytaped has joined #dri-devel
frytaped is now known as Guest2847
<karolherbst> why is intels GPU ISA
<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
<dcbaker> yes
<dcbaker> yes we do
<karolherbst> mhh cmp.l.f0.0(32) g9<1>HF g120<16,16,1>HF 0x7c00HF { align1 };
Xogium has left #dri-devel [leaving channel]
<dcbaker> HdkR: If you can add the fixes tag (i found the commit) you have my r-b on that
<karolherbst> werid...
iive has joined #dri-devel
sravn has quit [Remote host closed the connection]
sravn has joined #dri-devel
<HdkR> dcbaker: Alright, will add the tag
<dcbaker> swee, thanks! (makes my job of pulling it back to 22.1 easier :)
rsjw has quit [Quit: rsjw]
pcercuei has quit [Quit: dodo]
Duke`` has quit [Ping timeout: 480 seconds]
kallisti5[m] has joined #dri-devel
viciouss[m] has joined #dri-devel
<karolherbst> yeah.. so the intel driver is wrong :(
<HdkR> womp womp, non-conformant
<karolherbst> super annoying
* airlied has a vague memory of the cts running in cpu and gpu mode where it had different fpu expectations
<karolherbst> yeah.. I thought that too
<karolherbst> but in this case iris is wrong
<karolherbst> 0xB8002001 rounded up converted to fp16 is definetly 0x8200, and not 0x8202
<karolherbst> the nir shader agrees with the former
<karolherbst> but iris gives the later
<karolherbst> something very subtle going wrong inside nextafter
Leopold has quit [Ping timeout: 480 seconds]
Leopold has joined #dri-devel
vup has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
hikiko_ has joined #dri-devel
gouchi has quit [Remote host closed the connection]
hikiko has quit [Ping timeout: 480 seconds]
<karolherbst> but intel gives me 1 here... :/
<karolherbst> and I am quite sure I did the nir math correctly
<airlied> some magic flag will exist probably
<karolherbst> it's weird I get 0x1 though, because in the CTS run I got 0x8202 which is still wrong, but different wrong
<karolherbst> this is all wrong on the GPU though
<karolherbst> ehh let me print the half float imm
<karolherbst> done
<karolherbst> I suspect that iris HF handling _might_ be bonkers
danvet has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
nielsdg has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Labnan[m] has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
<karolherbst> huh...
<karolherbst> feq fp16 with 0x0000 is true :O although the value isn't 0x0000
<karolherbst> yeah.. somehow feq and fneu are broken
<karolherbst> or maybe bcsel with 16 bit sources?
<karolherbst> hard to tell
Ella[m] has joined #dri-devel
<karolherbst> airlied: btw, this test passes on llvmpipe, so I am really convinced this is an iris bug in the end
Leopold has quit []
moben[m] has joined #dri-devel
vup has joined #dri-devel
<karolherbst> yep...
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
gnustomp[m] has joined #dri-devel
<illwieckz> another bug bites the dust
sigmoidfunc[m] has joined #dri-devel
iive has quit [Quit: They came for me...]
tarceri__ has quit [Ping timeout: 480 seconds]
tarceri has joined #dri-devel
heat_ has quit [Read error: No route to host]
heat has joined #dri-devel
PiGLDN[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
nyorain[m] has joined #dri-devel
ppascher has joined #dri-devel
cphealy has quit [Ping timeout: 480 seconds]