simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
kugel is now known as Guest5445
kugel has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
Guest5445 has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
mbrost has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
iive has quit [Quit: They came for me...]
iyes has joined #dri-devel
yyds has joined #dri-devel
mbrost has joined #dri-devel
alane has quit []
alane has joined #dri-devel
lucadinh11 has joined #dri-devel
lucadinh11 has quit []
iyes has quit [Ping timeout: 480 seconds]
flynnjiang1 has joined #dri-devel
iyes has joined #dri-devel
flynnjiang has quit [Ping timeout: 480 seconds]
Net147_ has joined #dri-devel
OftenTimeConsuming is now known as Guest5459
OftenTimeConsuming has joined #dri-devel
Guest5459 has quit [Ping timeout: 480 seconds]
Net147 has quit [Ping timeout: 480 seconds]
thaytan has quit [Ping timeout: 480 seconds]
sukuna1 has joined #dri-devel
thaytan has joined #dri-devel
sukuna2 has joined #dri-devel
Company has quit [Quit: Leaving]
sukuna1 has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
kugel has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
sukuna2 has quit [Ping timeout: 480 seconds]
flynnjiang1 has quit [Read error: Connection reset by peer]
i-garrison has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit []
mbrost has joined #dri-devel
u-amarsh04 has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
rz_ has quit [Remote host closed the connection]
rz has joined #dri-devel
rsalvaterra has quit [Remote host closed the connection]
rsalvaterra has joined #dri-devel
yyds_ has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
epoch101 has quit []
glennk has joined #dri-devel
i-garrison has joined #dri-devel
Duke`` has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
Kayden has joined #dri-devel
fab has joined #dri-devel
coldfeet has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
sudeepd has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
yyds_ has quit [Remote host closed the connection]
sudeepd has joined #dri-devel
<urja>
Okay so, this is a quick "if someone has an idea" kind of question... basically, i've built my own linux system (armv7h / for the ASUS C201)
<urja>
and i built mesa with panfrost,kmsro,swrast (no llvm so softpipe)... the thing is, in weston i get panfrost just fine, but if i'm running sway i get softpipe
<urja>
(and an error message about mesa looking for zink dri)
<urja>
mesa 24.0.5, weston 13.0.0, sway 1.9 (if any of those mattered)
warpme has joined #dri-devel
warpme has quit []
warpme has joined #dri-devel
sudeepd has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
kts has joined #dri-devel
jsa has joined #dri-devel
yyds has quit [Remote host closed the connection]
sima has joined #dri-devel
yyds has joined #dri-devel
<kode54>
that's got EGL, right?
<kode54>
(probably a dumb question)
<urja>
I assume so :P, i can run eglgears_wayland in both situations
<urja>
just in sway its 18 fps softpipe vs in weston i get smooth (vsync-locked i assume) panfrost
<urja>
okay actually idk about the fps because eglgears does not print it, but i can see it (and glxgears in the same situation is 18 fps)
kts has quit [Ping timeout: 480 seconds]
frankbinns has quit [Ping timeout: 480 seconds]
<kode54>
emersion: should urja drop into #sway on libera.chat with this too?
* emersion
reads
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<emersion>
aha, i thought it was a weston question, but that was just a disguise!
<kode54>
yeah, weston was thrown in as an example of something that is apparently behaving
<urja>
yeah weston is the reference system that's working as it should (so i dont know why sway isnt) :P
<emersion>
can you obtain debug logs of sway? (sway -d >sway.log 2>&1)
<emersion>
and yeah, #sway is probably a better place
* urja
is reading over the debug log now....
<urja>
again a thing i didnt realize to do (because i'm not familiar with sway so i didnt realize that was an option, somehow)
<emersion>
what is your display driver btw?
tzimmermann has joined #dri-devel
<urja>
rockchip (as in, RK3288 running the integrated panel over eDP, so rockchip drm in the kernel for the display... panfrost for the rendering)
<tzimmermann>
airlied, i'm going to send the drm-misc-fixes PR in a minute. sorry for being late this week
<urja>
i took a log where i ran eglgears_wayland for a couple of seconds and then closed sway again
<emersion>
can you confirm that wlroots has been built with GLES2 support?
<emersion>
/usr/include/wlr/config.h should tell
<emersion>
(WLR_HAS_GLES2_RENDERER)
frankbinns has joined #dri-devel
<emersion>
can you try forcing WLR_RENDERER=gles2 in the env, just to see the error?
fab has joined #dri-devel
<urja>
oo, wlroots... yeah it might not be
<urja>
context: i tried building the system without GLES2 until i realized weston can't do desktop GL, then enabled GLES2... but i think i didnt rebuild wlroots (only sway itself, umm)
<emersion>
makes sense
<urja>
"I'm building a desktop setup, what do i need GLES2 for" *disables GLES2 for faster build* then *hours later* "oh, everyone is using GLES2 now, right, didnt know"
<emersion>
yeah, GLES is basically a trimmed-out version of desktop GL
apinheiro has quit [Quit: Leaving]
<emersion>
so using GLES gives wider hw support than desktop GL
<emersion>
trimmed-down*
<urja>
yes "Cannot create GLES renderer: disabled at compile-time"
<emersion>
aha!
<emersion>
we could probably better log this situation
<emersion>
in the case where the renderer is auto-selected'
kts has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
iyes has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
warpme has quit []
pcercuei has joined #dri-devel
<javierm>
tzimmermann: hi, I was about to ask if you noticed the simpledrm thread but I see you answered already and also pq
<urja>
yes, this is the package for which i had to give an empty list of renderers to build (i didnt have vulkan nor gles2), and wondered that "that's weird" and then forgot about when i was enabling gles2
<urja>
Thank you a bunch, it works now (glxgears running in vsync under sway)
<tzimmermann>
javierm, sure. i did
kts has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: yeah me too. But didn't notice pq and your answer before sending mine
mvlad has joined #dri-devel
<tzimmermann>
we all typed in parallel (or concurrently?)
<pq>
haha
<pq>
did we agree?
<tzimmermann>
afaiu we all said that userspace needs better hotplugging support
<pq>
seems so
<javierm>
yeah
<pq>
does simpledrm actually do what's doc'd for hot-unplug?
<tzimmermann>
pq it does
<pq>
cool
<tzimmermann>
it's trivial. the only operation to handle is a pageflip
azerov has quit [Quit: Gateway shutdown]
<javierm>
pq: the tricky part is for real drivers to decide when to kick out the video devices that conflict with their aperture
kts has joined #dri-devel
<javierm>
if they do it too early, then cold be that their probe fails and the machine doesn't have a video output anymore
<javierm>
but if they do it too late, it may be that simpledrm stops working anyways because the driver messes with the system framebuffer setup
<javierm>
simpledrm is realy just a best effort...
warpme has joined #dri-devel
<tzimmermann>
what javierm says ^, and i don't think we can give any guarantees for anything here. and simpledrm is still a best-case scenario. in a worst case, the user could hotunplug device 1, and only then physically plug-in device 2. userspace should still be able to survice that.
<javierm>
what I'm trying to say is that the gap between /dev/dri/card0 goes away and a /dev/dri/card1 is registered may vary per DRM driver, but still doesn't change the fact that user-space needs to cope with hotplugging
lynxeye has joined #dri-devel
<javierm>
tzimmermann: indeed. It could be doing a rmmod or the bind/unbind sysfs entries
<emersion>
but it's a bit tricky to handle in user-space
zxrom has quit [Read error: Connection reset by peer]
<emersion>
in particular, the DRM device is used to decide what kind of renderer is created on startup (GL on same GPU, software rendering, etc)
<derr>
everyone have a drm device... ? -ubernoob
<derr>
i cant choose between software and opengl in my cs anymore.
zxrom has joined #dri-devel
<derr>
'responsible for interfacing with gpu' i dont even have a real gpu i think so, guess not.
<tzimmermann>
emersion, how does userspace handle multi-gpu output? for example, a gpu on pci plus a usb-attached display?
<tzimmermann>
how does it pick a renderer?
<emersion>
most user-space has a concept of "primary GPU"
<emersion>
primary GPU goes away, compositor goes down
<tzimmermann>
i see
<derr>
i was here a while ago having my mesa drivers fixed, in the process , there are some minor font issues, i try to export LC_ALL="en_US.UTF-8" but not working. for steam\counter-strike.. anyone have experience ?
<jadahl>
what is the simpledrm thread that is to some degree about hotplugs?
<tzimmermann>
emersion, in EGL, there used to be a EGL_CONTEXT_LOST event that signealled that the rendering context became invalid. i assume that the compositors would have to reintialize their graphics output on hotplugs of the primary device and send out such an event to all applications (?) and then it becomes the applications problem (?)
<jadahl>
is it the same thing as before about compositors launching with simpledrm before the real driver becomes ready?
<emersion>
tzimmermann: yes, some compositors do that already, and that is easy to do because you're more or less guaranteed that you'll end up with a new GPU context that looks the same as the old one
<jadahl>
in the past discussions about it, I tried to make it clear that it is not ok to launch the compositor during the pre-real-driver phase, because it screws up how the initial animations behave
apinheiro has joined #dri-devel
<emersion>
tzimmermann: it becomes trickier when you have intermediate state with no GPU at all, or when the pixel formats change, etc
<emersion>
*supported pixel formats
<jadahl>
(ignoring the part about primary-gpu-unplug not working anywhere, which arguably is a different but related bug)
<tzimmermann>
emersion, i suggested to keep the primary device's devfile open until a new primary device shows up. there's no need to signal context-lost before that
<emersion>
do we even have a GPU context with simpledrm?
<tzimmermann>
jadahl, there's no way of knowing that a real driver will be comming. sometimes simpledrm is all you get
<tzimmermann>
emersion, only for software rendering
<emersion>
wouldn't the compositor start with software rendering with simpledrm, and then need to switch to GL when the real driver takes over?
<tzimmermann>
but simpledrm is a special case of a larger problem
RAOF has quit [Remote host closed the connection]
<emersion>
switching from a software renderer to a GPU one wouldn't really be possible
<jadahl>
tzimmermann: I know that, but there are ways "around" it (in theory), e.g. dumb timeout, drivers notifying that they are starting to load, and then after initial probe say the didn't find anything, and so on
<tzimmermann>
emersion, IDK what userspace uses for softwar rendering
<emersion>
dumb buffers, pixman
<emersion>
(or llvmpipe maybe)
<jadahl>
tzimmermann: what is not acceptable is starting e.g. gdm with simpledrm, then switching to a real GPU a second later
<jadahl>
as it creates a terrible user experience
<tzimmermann>
jadahl, it's a distributed system. none of these solutions will solve the problem. you don't know whether a native driver is comming
RAOF has joined #dri-devel
<emersion>
yea
<jadahl>
tzimmermann: even if its not solvable in 100% of the cases, I can't imagine it's not solvable for the majority
bolson_ has joined #dri-devel
<jadahl>
not to mention that from userspace's perspective, it's a regression
<jadahl>
(majority of users, e.g. normal system with a amdgpu attached etc)
bolson has quit [Ping timeout: 480 seconds]
<jadahl>
I agree that hot-unplug is something that should be supported by userspace, but for e.g. a regular computer with a amdgpu to no longer being able to get a decent looking login experience is a regression no matter how you see it
<emersion>
also hot-unplug support is not something you can quickly implement, in general it requires very intrusive major changes to userspace
<tzimmermann>
jadahl, even with the old fbdev drivers, it's always been like that. back then we had bugs where we had to disable the output to fix the boot
<jadahl>
I imagine if it'd happen, the screen in some cases would go from bland to bright, or bad gradients to good gradients, etc, if the real gpu driver has graphics capabilities the simpledrm one hasn't
<jadahl>
tzimmermann: something made it "work", because I have no memories of bug reports about it until simpledrm->real-drm-driver transitions started to happen
<jadahl>
either way, why can't drivers coordinate with the kernel about "probing started, probing ended, found N relevant devices" ?
<tzimmermann>
just shouting "regression" is not helpful IMHO. the first priority should be to work around these crashes. and my comments on the start-up timeouts was a reminder that the problem is not just in simpledrm. it's any hotplugging
<karolherbst>
it feels this entire problem space would go away if compositors would move away form "single rendering context" model
<karolherbst>
which they should do anyway
<jadahl>
karolherbst: no, it wouldn't
<emersion>
karolherbst: yes, but loooots of work
<karolherbst>
why not? If your driver changes, then it's just like moving to a different display (e.g. for muxed internal ones)
<emersion>
we don't disagree here, but the current model still needs to keep working
<karolherbst>
yeah, fair
<jadahl>
karolherbst: the problem is that when we boot, and and end up at the gdm screen, we'll "soft animate" the login gui elements. with simpledrm, we always disable animations, so they'd just plop up
<tzimmermann>
jadahl, because driver modules come and go, and hardware devices come and go. there is no start-probing/end-probing
<emersion>
jadahl: why do you disable animations?
<karolherbst>
jadahl: yeah, but a compositor being able to handle "the gpu for this display changed" would also be handle "the driver changed" situations
<karolherbst>
*be able to
<jadahl>
emersion: because animations + software rendering isn't a good combination
<emersion>
i got confused by the "soft animate"
<karolherbst>
probably at least
<jadahl>
emersion: soft as in "smoothed in"
<jadahl>
I should just have said "animate"
<jadahl>
:P
<emersion>
yeah, i parsed it as "software rendered animation" :P
<jadahl>
karolherbst: I don't think there is any disagreement about compositors being able to handle unplugs etc, it's primarily about the boot experience no longer working properly
<emersion>
right, so you want to animate, because there's a real GPU, but can't know the GPU will be coming soon
<karolherbst>
yeah, fair
<daniels>
(also you're going to need to keep copies of everything you uploaded to GL and recreate that)
<tzimmermann>
jadahl, emersion, flickering animations could maybe be fixed by drivers by cleverly transfering DRM atomic state from the old device to the new device. but that's likely different problem
<emersion>
daniels: GPU resets!
<daniels>
\o/
<jadahl>
emersion: and/or show anything, because HDR/DeepColor needing real gpu drivers and what not
<jadahl>
tzimmermann: that's not enough. we never want to animate with simpledrm, so there would be no animation
<emersion>
DeepColor™, is that an AI-powered thing? x)
<karolherbst>
....
<jadahl>
:D
dviola has quit [Quit: WeeChat 4.2.2]
rasterman has joined #dri-devel
<jadahl>
anyhow, the only place I can imagine being able to make a somewhat educated guess whether the kernel have done any initial probing and whether any drivers are probing anything, is the kernel. the only work arounds I can think of that userspace can do is while (!is_hw_accel() || !arbitrary_timeout_reached()) wait_on_udev()
<emersion>
yeah
f_ has joined #dri-devel
sgruszka has joined #dri-devel
<derr>
karolherbst: u wanted to try compile some version 23 of mesa or such on my system for, some reason ? i remember saying yes to something i had no clue what was =)
<derr>
you may, (instruct me) if you want and need. think i already have mesa 23 tried and installed with steam tough
jkrzyszt has quit [Quit: Konversation terminated!]
gigigonzalo has joined #dri-devel
gigigonzalo has quit [Remote host closed the connection]
crewtorned has joined #dri-devel
<kode54>
congrats to gfxstrand on the command queue merging finally reaching merge ready status
oneforall2 has quit [Remote host closed the connection]
crewtorned has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<zmike>
yes, gfxstrand has been hard at work on it for months
<Ermine>
Is ANV a Vulkan driver for Intel GPUs ?
<Sachiel>
yes
kugel is now known as Guest5723
kugel has joined #dri-devel
Guest5723 has quit [Ping timeout: 480 seconds]
bolson has quit [Remote host closed the connection]
bolson has joined #dri-devel
ramamonacius has joined #dri-devel
<jenatali>
Any spec lawyers around?
<jenatali>
The GL spec section 9.3 says "Specifically, the values of rendered fragments are undefined if any shader stage fetches texels and the same texels are written via fragment shader outputs"
<jenatali>
Does a clear count as a fragment shader output?
feaneron has quit [Ping timeout: 480 seconds]
<zmike>
no
smpl has quit [Ping timeout: 480 seconds]
<jenatali>
So binding a framebuffer for both input and output, and then clear, draw doesn't constitute a feedback loop and so no TextureBarrier is needed?
<zmike>
you mean doing fbfetch?
<jenatali>
No, not fbfetch
<zmike>
not sure what you mean by input and output then
<jenatali>
Binding a framebuffer for output, and also binding one of its attachments as the texture to one of the sampler units
<jenatali>
(Hopefully I get my GL terminology right)
<zmike>
ah
<jenatali>
The spec says it's legal to do texel fetch, not framebuffer fetch, for the current pixel in the fragment shader, as long as you have a TextureBarrier since the previous write - but it only qualifies that as needed in the case of fragment shader outputs
<zmike>
and in this scenario your fb attachment which is also a sampler is not being written?
<zmike>
by the fragment shader, that is
<jenatali>
There's a single draw which is a feedback loop. It reads and writes the same texture
<zmike>
is this a piglit or a cts case
<jenatali>
The prior write is from a clear though, not a fragment output
<jenatali>
No, real-world app
<zmike>
huh
<jenatali>
And so I'm trying to decide between declaring app bug, they need a texture barrier, or if I need to do unnatural things in my driver to make it work
<zmike>
that's basically an input attachment (fbfetch), where you're supposed to barrier
<zmike>
I've seen the case where a fb attachment is used as a sampler without writing to it
<zmike>
not sure I've seen your case though
<zmike>
I'd have to check the spec, which I can't easily do from my couch
<jenatali>
Yeah, it's basically an input attachment. But it's at the start of a subpass where the attachment load op is clear
<jenatali>
In VK it's more naturally expressed
<zmike>
right, but in that case you'd need a barrier too
<jenatali>
Oh you do?
<zmike>
yes
<jenatali>
Cool then I'm going to claim app bug
<zmike>
there's cts coverage for clear -> fbfetch which works like this
<zmike>
though technically it's advanced blend which is lowered to fbfetch
<zmike>
implementation detail
<jenatali>
But it's not strictly fbfetch, this is a feedback loop, i.e. input attachment that's also an output attachment
<jenatali>
Which can be used to implement advanced blend
<zmike>
yeah, like I said I'd have to check the spec to be lsure
<zmike>
I'm just comparing to existing mechanics
<jenatali>
Alright fair enough, I'm going to pose it to Adobe to see if they'll fix it
<zmike>
it sounds like an app bug fwiw, but this is not an official 🪑 statement
<jenatali>
Yeah, sounds like an app bug to me too but I like to have some evidence before claiming that :)
ramamonacius has quit [Remote host closed the connection]
ramamonacius has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<ramamonacius>
Think of your new life as a worm after we kill you all off! Tbh. I am long time supporting chinese and russians based of their sanity and bravery and no solidarity and cheater politics, you are so nasty people in the western world, why would others have to suffer due to your actions? And why the fuck does it take so long to get rid of you? I thought the fuckers get handled by vaccines, but still the joss discrimination mob
<ramamonacius>
tells lies and abuses me. You are so big garbage in our planet.