<sumits>
tzimmermann, mripard: I'm trying to push to drm-misc-next, but get an error 'You are not allowed to push code to this project'. Has something changed?
feaneron has joined #dri-devel
glennk has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
smpl has joined #dri-devel
<wens>
it seems someone pushed a commit to drm-misc-next-fixes when it likely should have been to drm-misc-fixes
fab has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
mripard has joined #dri-devel
warpme has joined #dri-devel
rasterman has joined #dri-devel
u-amarsh04 has quit []
amarsh04 has joined #dri-devel
rossy has quit [Remote host closed the connection]
rossy has joined #dri-devel
LeviYun has quit [Read error: Connection reset by peer]
robmur01 has quit [Read error: Connection reset by peer]
robmur01 has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
<jenatali>
kusma: 🤔 we stood up a new runner, but it's passed those jobs before so it shouldn't be that
<jenatali>
I've seen those assertions before. I think mareko hit them a little while ago? I don't remember exactly
<kusma>
jenatali: BTW, it also seems like the d3d12 tests don't run in the nightly schedule, which makes it a bit hard to check what's *supposed* to happen...
<mripard>
sravn: the dw-hdmi layer has mostly been done by jernej, so make sure he's in Cc if you send any patches
<mripard>
but yeah, it looks like something we should address
kzd has joined #dri-devel
jsa has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
Company has joined #dri-devel
cheako has joined #dri-devel
warpme has quit []
drU5Q7gM has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
yyds has joined #dri-devel
<stsquad>
Why does mesa's meson complain about wanting to build GLX if I'm doing "meson setup -Dbuildtype=release -Dplatforms=wayland -Dvulkan-drivers=virtio" - or does OpenGL default on?
* stsquad
tries with -Dglx=disables for now
kts has quit [Ping timeout: 480 seconds]
<zmike>
-Dgallium-drivers=
<stsquad>
zmike ahh thanks - actually I went for -Dgallium-drivers=virgl - I guess GLX is for older GPU drivers?
<zmike>
glx is for all gl drivers
Calandracas has quit [Remote host closed the connection]
simon-perretta-img has quit [Ping timeout: 480 seconds]
Calandracas has joined #dri-devel
simon-perretta-img has joined #dri-devel
vliaskov has quit [Read error: No route to host]
kts has joined #dri-devel
<Company>
on 24.1 (and Intel), do Vulkan and GL use different Wayland protocols?
<Company>
like, one using drm_syncobj and the other not?
<dj-death>
the wayland stuff is shared across drivers
<dj-death>
on vulkan
<dj-death>
and actually on GL too
<dj-death>
but yeah different code paths, different rules
<dj-death>
I remember explicit sync was added to vulkan
<Company>
I guess I can just run WAYLAND_DEBUG and grep for it
<Company>
yup, Vulkan creates a sycobj, GL does not
<dj-death>
could be that the surface is out of sync and it's not updating it again, just doing a blit?
<Company>
then everyone would have that issue, but that just happens for one person with an external monitor
<Company>
so I'm tempted to blame mutter
<Company>
could also be that the Vulkan code is busted and fails to update the buffer - though I'd say that's unlikely because GTK recreates the swapchain so it's independent of the syncobj
guludo has quit [Quit: WeeChat 4.2.2]
* Company
assigns bug to Mutter so swick[m] and MrCooper can have a look
feaneron has joined #dri-devel
warpme has joined #dri-devel
fireburn has quit []
guludo has joined #dri-devel
feaneron has quit [Quit: feaneron]
feaneron has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
x512[m] has quit []
alyssa has joined #dri-devel
<linkmauve>
alyssa: Citra uses a GS for everything because that’s what the hardware does, it has vertex shaders and geometry shaders, but no fragment shaders as that is replaced with a fixed pipeline.
<alyssa>
linkmauve: amazing (:
Calandracas has quit [Remote host closed the connection]
neobrain[m] has joined #dri-devel
Calandracas has joined #dri-devel
<neobrain>
Couldn't quickly find the context of the discussion, but IIRC there is a software fallback for the 3DS geo shaders
<neobrain>
That fallback is actually needed for accurate emulation, since 3DS GS doesn't trivially map to host GS. Specifically certain types of vertex attributes have different interpolation rules
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
balrog has quit [Quit: Bye]
balrog has joined #dri-devel
fab has quit [Quit: fab]
Calandracas_ has joined #dri-devel
Calandracas_ has quit [Remote host closed the connection]
<alyssa>
neobrain: context was "I spent a week making GS fast on M1 in January when I found out how hard Citra hammered them"
Duke`` has joined #dri-devel
Calandracas_ has joined #dri-devel
Calandracas has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
Calandracas_ has quit [Remote host closed the connection]
sewn has quit [Remote host closed the connection]
<FL4SHK[m]>
is writing a Mesa based driver difficult?
<FL4SHK[m]>
for a fully programmable GPU
<Ermine>
I guess so
<FL4SHK[m]>
hm
Calandracas has joined #dri-devel
Agent_00Ming has joined #dri-devel
<Ermine>
GPUs are hard. I'm pursuing to become contributor to linux graphics stack, but so far I haven't figured it out
<FL4SHK[m]>
I'm a hardware dev
<FL4SHK[m]>
And a software dev
<FL4SHK[m]>
and I have this project that I may be working on for the rest of my life
sewn has joined #dri-devel
<FL4SHK[m]>
FPGA-based "PC" things
<FL4SHK[m]>
I have this FPGA dev board with a large FPGA (~500k logic cells)
<zmike>
kusma: for your mipmap question it would probably be good if you could be on the next call (2 weeks from today)
<FL4SHK[m]>
I've been working on the fixed function part of the GPU so far
<FL4SHK[m]>
... though I'm still learning
<FL4SHK[m]>
I can do the programmable part just fine, but the actual 3D rendering part is new to me
<FL4SHK[m]>
so I'm writing a software based 3D renderer to learn the fixed function aspects of GPUs
<FL4SHK[m]>
... basically I plan to translate my software rasterizer into FPGA code
<pac85>
alyssa: right I should have figured... Anyway seriously congrats!
<Company>
and then another month for writing a blog post - life of a coder
<alyssa>
pac85: thanks!!
<alyssa>
Company: if I can write the driver in 26 days I can write the blog post in 26 hours
<alyssa>
:P
* alyssa
started writing on Monday night... :p
<Company>
the other 25 days are for thinking "I should write a blog post" :p
<alyssa>
Yup
Calandracas has quit [Remote host closed the connection]
<Ermine>
alyssa: magnificent work!
<Company>
alyssa: was it on purpose that the zink screenshot has 1/3rd the fps of the Vulkan screenshot?
<alyssa>
Ermine: thanks!
<alyssa>
Company: stk's vulkan renderer doesn't implement any of the expensive lighting passes their gl does
<alyssa>
but also zink on honeykrisp is like 1/3 the speed of our native gl
<Company>
why is that?
<zmike>
I'd assume because it's a tiler and the vendor id hasn't been added to the tiler paths in zink
sukuna has quit [Remote host closed the connection]
<Company>
because Vulkan isn't optimized yet? Or because Vulkan can't be as optimized?
<Company>
zmike: what do tiler paths do differently?
<zmike>
everything
<Company>
hehe
warpme has quit []
<Agent_00Ming>
Hi, I have encountered an issue concerning GL_INVALID_VALUE error being thrown by the nvidia proprietary driver when the same parameters work without trouble on AMD and Intel
<Company>
I should learn about what's important to do different on tilers at some point
<alyssa>
that's probably some of it, also honeykrisp is slow right now because it was written in a month, etc
Calandracas has joined #dri-devel
sukuna has joined #dri-devel
<Agent_00Ming>
Does anyone have a clue as to why GL_INVALID_VALUE is thrown even when the texture has level:0, x:0, y:0, width:24, height:24?
<zmike>
alyssa: a simple copy/paste of most TURNIP vendor id checks for whatever you're using will probably see sizable improvements
<FL4SHK[m]>
<alyssa> "FL4SHK: I don't think 500k is..." <- really? 500k is a ton for an FPGA
<zmike>
good pick of holocure for a demo though
<FL4SHK[m]>
it's not the same as 500k transistors
<alyssa>
zmike: probably. i'm more interested in dxvk :)
<zmike>
you do you
sgruszka has joined #dri-devel
<FL4SHK[m]>
That and I don't expect to reach performant 3D at modern resolutions
<FL4SHK[m]>
I could buy a bigger FPGA
<alyssa>
FL4SHK[m]: fair enough. I just remember looking at this and seeing that geezus gpus are area intensive because 1000s of FPUs
<FL4SHK[m]>
an FPU for a GPU doesn't have to be fully IEEE 754 compliant
<FL4SHK[m]>
what's a geezus GPU?
<FL4SHK[m]>
a modern one?
<FL4SHK[m]>
Modern GPUs aren't in the same class as what you can do with an FPGA
<FL4SHK[m]>
even a really high end FPGA
<stsquad>
haven't there been a number of open source projects that attempted to do 3D with an FPGA?
<FL4SHK[m]>
Maybe, but I'm mostly doing this for me anyway
<FL4SHK[m]>
I can open source the project though
* stsquad
seems to remember there have been re-occuring attempts mainly driven by the poor state of open drivers in the past
<FL4SHK[m]>
ah
<FL4SHK[m]>
FPGAs don't reach the clock rates of modern COTS GPUs
<FL4SHK[m]>
I'd be pretty happy with a 300-400 MHz GPU for my own project
<FL4SHK[m]>
might go higher, but likely not as high
<karolherbst>
still sad about the split db stuff not working
LeviYun has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
sgruszka has quit [Ping timeout: 480 seconds]
<clever>
ive got a problem that has been plauging my desktop for months now, anybody know how i could debug it further? [74306.977576] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=33463961, emitted seq=33463963
fab has quit [Quit: fab]
rasterman has quit [Quit: Gettin' stinky!]
mohamexiety has quit [Read error: Connection reset by peer]
epoch101 has joined #dri-devel
mripard1 has quit []
mbrost has joined #dri-devel
Agent_00Ming has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
bolson has joined #dri-devel
Agent_00Ming has joined #dri-devel
Agent_00Ming has quit []
LeviYun has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
vliaskov has joined #dri-devel
LeviYun has joined #dri-devel
guludo has quit [Quit: WeeChat 4.2.2]
guludo has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
epoch101_ has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
agd5f has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
epoch101_ has quit []
epoch101 has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
epoch101 has quit []
<marex>
eric_engestrom: Hi, I think the mesa tag mesa-24.1.1 should again be in branch 24.1 instead of staging/24.1 ?
<marex>
it seems like only 24.1.0 is in 24.1 branch , not 24.1.1
drU5Q7gM_ has joined #dri-devel
drU5Q7gM has quit [Read error: Connection reset by peer]
<mattst88>
marex: it looks like he just forgot to push to 24.1
<marex>
could be
<dwfreed>
tags aren't branch specific
devnull[m] has left #dri-devel [#dri-devel]
Haaninjo has quit [Quit: Ex-Chat]
imre has quit [Read error: Connection reset by peer]
<gfxstrand>
Why doesn't nir_lower_idiv support int64?!?
<gfxstrand>
I know it would probably want fp64 but still...
imre has joined #dri-devel
<gfxstrand>
The integer divide lowering in lower_int64 sucks so bad....
<alyssa>
gfxstrand: because we already had the lowering in int64
<alyssa>
i think
<alyssa>
you could move it to idiv but then we'd ask why doesn't nir_lower_int64 support idiv?!?!
<alyssa>
;)
<gfxstrand>
Well, they're fundamentally different approaches.
<gfxstrand>
I'd be happy to have something in lower_idiv which gets invoked by lower_int64 so you can access it from either pass.
<gfxstrand>
But generating a division algorithm if-ladder is just absurd
<gfxstrand>
Seems to be a good stress-test for NAK, though. :joy:
mbrost has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<alyssa>
gfxstrand: fair enough
<gfxstrand>
Reading the AMD LLVM code makes me sad
<gfxstrand>
They do the same thing except on some platforms they emit a different thing that's still like 50 instructions or more
cheako has quit [Quit: Connection closed for inactivity]
<airlied>
gfxstrand: the amd code in llvm? or the amd llvm code in mesa?
<gfxstrand>
AMD code in LLVM
mbrost has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
vliaskov has quit []
<karolherbst>
I thought the solution to 64bit idiv is to not bother, because people hitting real 64bit idiv obivously don't care about performance :P
<mareko>
in this market, if you are slow at something, the competition will use it against you
<HdkR>
Someone might implement the slowest/smallest radix divider and beat the lowered version :P
Duke`` has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
<eric_engestrom>
marex, mattst88: I didn't forget, I purposefully didn't push yet because each of these push triggers a CI pipeline and the CI is overwhelmed with everyone doing everything they couldn't do for the last couple of days (mostly trying to merge stuff), so I'm going to push the missing bits tomorrow morning once everything has died down
<mattst88>
ah, cool. thanks
<eric_engestrom>
I also only did the 24.1.x release and not the 24.0.x, for the same reason
<marex>
eric_engestrom: ahh, thanks
<marex>
eric_engestrom: no rush from my side, I just noticed it while bumping the mesa version locally so I reported it
<eric_engestrom>
yeah no worries, I have forgotten to do the final push a few times in the past so it could well have been the case today as well ^^
oneforall2 has quit [Remote host closed the connection]
<eric_engestrom>
also, I'm going to post an MR disabling most of the CI in the release pipelines, it's not very useful to run everything again, it's too late anyway and everything will have been run in the staging pipelines
<eric_engestrom>
but not tonight, I need to sleep now :P
oneforall2 has joined #dri-devel
jrelvas has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
<jrelvas>
i just had a shower thought... if a gpu has a good enough display controller, then it could be possible to offload the entire window opening/closing effect in a desktop environment to KMS
<jrelvas>
make sure the target window has its surface/buffer being scanned out by a hardware plane
<jrelvas>
for "opening", transition the alpha from 1 to 0 and transition the scale from 0x0y to the buffer's actual size
<jrelvas>
for "closing", transition the alpha from 0 to 1 and transition the scale from the buffer's actual size to 0x0y
LeviYun has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
LeviYun has joined #dri-devel
i509vcb_ has quit []
i509vcb has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
guludo has quit [Quit: WeeChat 4.2.2]
oneforall2 has quit [Remote host closed the connection]
PiGLDN[m] has quit []
mbrost has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<zmike>
eric_engestrom: 💪 💪 💪
nerdopolis has joined #dri-devel
LeviYun has joined #dri-devel
apinheiro has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
<Ermine>
What does "blorp" mean?
jewins has quit [Remote host closed the connection]