<Xogium>
hello folks :) I have hopefully a really quick question… I work with embedded systems, where we use mesa3d, and we are a bit confused. Buildroot has a mesa3d package… which is on v 21.1.8, yet still enables the swrast driver ? I thought that had been deprecated. Certainly everything I can readily find on internet seems to talk of the swrast driver as something very very old by now
<Xogium>
is our package broken ? Is it not deprecated at all in that release ?
<Xogium>
when I mean it can enable swrast, it just passes it during the build, as something to enable
<Xogium>
shouldn't it be softpipe/llvmpipe ? I'm beyond confused
tzimmermann has joined #dri-devel
kmn has joined #dri-devel
<Xogium>
adding to the confusion even more, even when I don't enable this driver in my build, the mesa loader tries to load kms_swrast and swrast driver
<Xogium>
why would it attempt that, if swrast has been deprecated for years ?
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
zf has joined #dri-devel
nroberts has joined #dri-devel
<HdkR>
Xogium: There's some voodoo where llvmpipe is the same driver name as the classic swrast.
pnowack has joined #dri-devel
<HdkR>
meson option for enabling llvmpipe is even called swrast. Same how lavapipe's meson option is swrast
<Xogium>
HdkR: oh, bloody hell
<Xogium>
sorry for swearing but, ugh
<Xogium>
thanks… Now I can understand what's going on and why the mesa loader keeps calling it swrast driver
<Xogium>
it's just an alias of sort
<pq>
"Let's write a new software rasterizer. What should we call it, hmm... it's a software rasterizer, so... swrast!" *sigh*
<pq>
although that rule was broken with the swr driver :-P
<Xogium>
pq: my point is, this has been deprecated. When you look at the mesa doc and see that swrast has been deprecated, and then you see your build system and mesa loader trying to load it anyway
<MrCooper>
pq: already with llvmpipe/softpipe
<MrCooper>
Xogium: different meanings of "swrast"
<pq>
maybe in the very early days, the intention was that the classic swrast DSO could be simply replaced with a gallium based swrast DSO...
<Xogium>
well
<Xogium>
its definitely not something I'd have guessed at…
<MrCooper>
the classic swrast driver is what's deprecated, not swrast_dri.so
<Xogium>
this makes it sound like it is trying to load *the* swrast driver
<MrCooper>
yep, it is
<pq>
MrCooper, no-one outside of the Mesa circles would realize that.
<MrCooper>
is there a need for them to?
<pq>
apparently, reading the above
<MrCooper>
not sure how that could be avoided (without otherwise useless churn)
<Xogium>
like I'm not saying it's bad… Honestly, just that it is very, very confusing
<Xogium>
I've been at this for hours before I threw the towel so to speak and came to ask you guys
<pq>
What churn would that have been, if the names of the other swrast implementations than the original classic swrast were called something else than swrast?
<pq>
from the beginning, that is
<MrCooper>
pq: alternative mechanisms for LIBGL_ALWAYS_SOFTWARE, e.g.
<pq>
MrCooper, I think we have already had several different mechanisms for that, e.g. EGL_SOFTWARE
<Xogium>
I almost went to ask the buildroot folks what to do about br apparently still packaging swrast deprecated driver… :/
<Xogium>
but decided to ask here first
<pq>
or some EGL_* variable that was
<MrCooper>
or even just the fallback to swrast_dri.so if the preferred driver fails to initialize
<pq>
MrCooper, ok, that's some, doesn't sound significant to have a priority list of fallbacks instead.
<pq>
Oh well. I agree things could be a lot clearer, and it can't be helped now.
<pq>
a bit like libwyland having two totally different definitions of 'struct wl_display' and three totally different definitions of 'struct wl_buffer' in the same project.
<pq>
(nowadays it's down to 1.5 definitions of wl_buffer)
<Xogium>
yeah, I'm not angry, just a bit annoyed at the confusion ;)
<Xogium>
I'm surprised that no software packager seem to have wondered about that, tbh
camus1 has quit [Remote host closed the connection]
<Xogium>
in buildroot we don't 'package', not in the same sense as distro would… but it sure gave me pause
<pq>
Xogium, I think they have went through the same confusion, just many years ago.
camus has joined #dri-devel
<Xogium>
buildroot still calls it swrast driver in the menuconfig
<pq>
it's funny how the current swrast is not even one driver, it's two alternatives built into one.
<pq>
and you choose between them with... and environment variable I can't remember
<Xogium>
softpipe and llvmpipe ?
<pq>
yup
<MrCooper>
and swr
<pq>
d'oh
<MrCooper>
GALLIUM_DRIVER can be used to override
<Xogium>
well… urgh. I think I need a break lol I have a monster headache
<Xogium>
thanks for explaining :)
<pq>
I guess all this hassle is because the concept of "alternative drivers for specific device" does not really exist?
<pq>
and swrast is really just a driver for "the CPU device"
<Xogium>
hm
zf has quit [Ping timeout: 480 seconds]
<pq>
then add some special case glue when a hardware driver fails to load to fall back to "the one" sw driver.
gawin has joined #dri-devel
<MrCooper>
there was a "fun" time when setting LIBGL_ALWAYS_SOFTWARE=1 could end up using zink with HW acceleration
<Xogium>
hm how's that work in qemu ?
<Xogium>
could I potentially use the same -vga / -device ...
zf has joined #dri-devel
<Xogium>
and have it fallback on software if it just won't work ?
<HdkR>
If a device driver fails to initialize then a software fallback usually occurs already?
<Xogium>
hmm I guess so yeah
<pq>
yeah, I meant the special glue is already in Mesa
<Xogium>
I've not built anything but virgl atm so when it fails, weston throws up
<Xogium>
but adding this software driver should make it fall back
<pq>
yeah, I think so - then it'll try kms_swrast I think to bridge the gap between KMS/GBM and swrast renderer
<Xogium>
also if I don't enable llvm support for mesa, then I guess it wouldn't work ?
<pq>
you could still get softpipe without llvm I believe
<pq>
softpipe is just so slow
<Xogium>
good then, llvm it is
<pq>
for Weston specifically, you'd be better off by telling Weston to use it's Pixman renderer instead of software GL.
pcercuei has joined #dri-devel
<pq>
but since software GL on GBM/KMS works (or at least should), Weston doesn't automatically fall back to Pixman
<Xogium>
oh ?
<Xogium>
I'm new to both mesa and weston… Being blind doesn't exactly help either
<Xogium>
but… I can get by, sort of
<pq>
maybe Weston should fall back to Pixman, but detecting that the GL implementation is a sw and not a hw driver is somewhat ugly
<pq>
Xogium, Weston has two renderers itself: one uses OpenGL ES 2 or 3, the other is a software implementation based on Pixman library.
<Xogium>
doing this for work so… I'm doing what I can, but I have someone sighted who can check
<pq>
I'm pretty sure the Pixman renderer would beat any software GL implementation easily, that's why it exists.
<Xogium>
hmm
<Xogium>
currently it doesn't seem to fallback to it, when virgl just doesn't work
<Xogium>
it just makes weston crash like in my pastebin
<pq>
no, it does not fall back automatically, you have to choose it
<Xogium>
well that's a bit of a problem…
<pq>
on command line --use-pixman, or in weston.ini I think
<Xogium>
so that would also override virgl ?
<pq>
for the rendering part yes.
<Xogium>
I'm a bit confused as to what's best really, pixman or virgl at this point
<pq>
I guess that depends on whether virgl ends up using host hardware.
<pq>
GPU
<Xogium>
because it can end up not using it ?
<pq>
I don't know virgl well enough to say.
<Xogium>
I thought that using host hw was the whole point behind virgl and virtio_gpu driver
<pq>
yes, I suppose so - I've never looked into it
<Xogium>
would probably work better than any software implementation then… I mean, I'd imagine so
<Xogium>
but I was kind of hoping for a fallback that would work on any machine no matter if it has the capability for using virgl or not
<Xogium>
but if you explicitly have to call on pixman, that wouldn't be a smooth fallback…
<pq>
If you want applications to be able to use the GPU, then Weston must use the GL renderer. Apps under Weston will not tend to use GPU if Weston runs with Pixman.
<pq>
Right. So a software GL driver will give you that automatic fallback, with the caveat that in Weston's case specifically it won't be as efficient as things could be. But it's probably enough.
<Xogium>
I'm not 100% sure myself… I just know we're using weston to launch cog, which is a sort of webkit launcher for access to panel of our hardware
<Xogium>
the idea is we're trying to make that also work in qemu, even though it is virtualized hardware
<Xogium>
so we can try things out easily enough, without requiring access to physical hardware
<pq>
Xogium, right. I would recommend going the software GL driver path first and see if that is good enough. I may well be, depending on your virtual screen resolution. Specifically llvmpipe.
<Xogium>
yeah. Will try that out, doing a build atm
<Xogium>
this will take about an hour or two even on the amd epic box… So will not know till then
<Xogium>
thanks a bunch guys, really appreciate the help
<Xogium>
will let you know how it goes
<pq>
no problem
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
mclasen has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
vivijim has joined #dri-devel
Company has joined #dri-devel
<gawin>
mareko: are VS on r300 hardware requiring usage of MOV to set output? (I've been reading docs, but I didn't find anything)
JohnnyonFlame has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
FireBurn has joined #dri-devel
nchery has joined #dri-devel
sdutt has joined #dri-devel
nsneck has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
camus has joined #dri-devel
X-Scale has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<zmike>
anholt: any idea why if I set a timeout of 180 with deqp runner I can still have a test run for 1260s?
X-Scale` has quit [Ping timeout: 480 seconds]
<Xogium>
pq: yay it works ! Well, almost as intended. You need 2 different qemu command lines to use either virgl or llvmpipe… but at least it doesn't involve altering the guest OS
MrCooper has quit [Remote host closed the connection]
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
<pq>
Xogium, do you mean that something fails if you use the virgl qemu command line but don't actually have a GPU?
<Xogium>
nah like… if you explicitely use -device virtio-vga-gl but set gl=off in -display to see if it will just fall back to software rendering it will just say, opengl is unavailable
<Xogium>
so you have to use -vga virtio -display gtk,gl=off, or -device virtio-vga-gl -display gtk,gl=on
<Xogium>
first one is to use a typical virtio gpu but with no opengl acceleration so weston does a fallback on software rendering
<Xogium>
second is to use the virgl driver
<pq>
Xogium, I'm curious what more you wanted to automate? If not the command line, then what would decide between software and hardware rendering?
<Xogium>
well I was sort of hoping that if qemu couldn't get virgl working, then it would use llvmpipe automatically
<Xogium>
that probably used to work back before 6.1 of qemu, but they split standard virtio and virtio-vga-gl into 2 different devices
MrCooper has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
<mareko>
gawin: no clue
mbrost has joined #dri-devel
nroberts has quit [Remote host closed the connection]
gawin has joined #dri-devel
ybogdano has joined #dri-devel
pnowack has quit [Read error: Connection reset by peer]
linearcannon has quit [Read error: Connection reset by peer]
pnowack_ has joined #dri-devel
pnowack_ has quit []
pnowack has joined #dri-devel
<anholt>
zmike: the timeout is actually handled as "time with no output printed from the test"
<zmike>
ah
Duke`` has joined #dri-devel
Xogium has left #dri-devel [leaving channel]
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
ybogdano has quit [Read error: Connection reset by peer]
jljusten has quit [Quit: WeeChat 3.3]
jljusten has joined #dri-devel
<jenatali>
Is there a label for changes to primconvert? I guess util?
gawin has joined #dri-devel
<FLHerne>
jenatali: several "util/primconvert: blah" commits recently
<jenatali>
Oh I meant a GitLab label, not a commit prefix
<jenatali>
I'm pretty sure I found a bug exposed by switching the d3d12 driver to threaded context and I just want to add a one-liner fix into my patch series so it doesn't regress, and I was hoping to add a label so people who care would be notified
<anholt>
jenatali: I'd use "gallium"
ybogdano has joined #dri-devel
<jenatali>
anholt: Sounds good, thanks
<zmike>
jenatali: don't worry, nobody will review it regardless 👍
* zmike
grumbles about util reviews
<jenatali>
Damn, didn't fix all of my regressions, but I don't repro the other ones locally :(
<jenatali>
Oh weird, now I do
<zmike>
jenatali: imo I'd split out all your non-d3d12 patches into a separate gallium MR to help in case you end up changing CI results
<jenatali>
zmike: Yeah, good point, that one-liner might fix other driver fails
<mareko>
zmike: I think we need to deprecate set_vertex_buffers and use pipe_vertex_state; the frontend should use VAO fields as a key to look up pipe_vertex_state and pass that to gallium, then gallium can hold the reference or TC can hold it instead
<jekstrand>
bnieuwenhuizen: RE: Dynamic rendering. My branch is about 80% of the way there then I got distracted by synchronization and threaded submit. :)
<jekstrand>
RE: Dynamic on top of render passes. That's what Sachiel did for us. It's totally backwards but also perfectly reasonable for the initial transition, IMO.
<Sachiel>
do you want me to post that as it is?
<jekstrand>
You can. Mabye bnieuwenhuizen can copy+paste from it?
<bnieuwenhuizen>
I was taking the same approach for RADV, so sounds like we might avoid some duplication?
oneforall2 has quit [Remote host closed the connection]
<zmike>
mareko: I was actually contemplating whether that would be viable...I really need stride to come with elements and that would solve a ton of problems for me
ybogdano has quit [Read error: Connection reset by peer]
oneforall2 has joined #dri-devel
<zmike>
jekstrand: but why look at that when you could just look at the R E F E R E N C E
<jekstrand>
zmike: :P
<airlied>
mripard: I'll check patchwork later, not sure I saw it there, will merge it today
unrelentingtech has quit [Quit: Reconnecting]
unrelentingtech has joined #dri-devel
ybogdano has joined #dri-devel
ybogdan has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
ybogdan has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
ybogdano has quit []
ybogdano has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
gouchi has joined #dri-devel
xantoz has quit [Ping timeout: 480 seconds]
<mareko>
zmike: I see no other way, it will also most likely not support interleaved attribs
<mareko>
actually the driver can analyze pipe_vertex_state and do whatever
<zmike>
feels like it may take a little iterating to get something we can be happy with
<mareko>
the frontend will just hand the VAO to the driver as a cached CSO and it's up to the driver to decide what to do with it
bluebugs has joined #dri-devel
moa has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
tzimmermann has quit [Quit: Leaving]
mbrost_ has joined #dri-devel
tjaalton has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
tjaalton has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
illwieckz has quit [Remote host closed the connection]
<zmike>
I'm planning to implement all of that in zink tomorrow, so I'll have a better understanding of it by the time you get something working
alatiera has quit [Read error: Connection reset by peer]
alatiera has joined #dri-devel
vivijim has quit [Quit: leaving]
gouchi has quit [Remote host closed the connection]
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
FireBurn has quit [Quit: Konversation terminated!]
nchery has quit [Quit: Leaving]
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
The_Company has joined #dri-devel
FireBurn has joined #dri-devel
<FireBurn>
Urgh my AMD Raven system isn't booting with linus's tip, drm-next or agd5f's drm-next, I've reverted back to 5.15 - I don't reboot that machine very often
<FireBurn>
Compiling amdgpu as a module got it a little further
Company has quit [Ping timeout: 480 seconds]
<FireBurn>
The last known good build of agd5f's tree was SMP Wed Oct 20 12:31:57 BST 2021
<FireBurn>
Which is before it switched to rc7 (from rc2)
<FireBurn>
When amdgpu was compiled as a module, the initual boot text showed but it didn't get modeset
<FireBurn>
I did however see this in the Xorg.0.log.old
<FireBurn>
(EE) AMDGPU(0): Failed to make import prime FD as pixmap: 22
<FireBurn>
If that helps
<FireBurn>
I'm jetting off in a couple of hours and won't be able to look into this for a couple of weeks
fxkamd has quit []
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
YuGiOhJCJ has joined #dri-devel
sdutt has quit [Remote host closed the connection]