ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
rasterman has quit [Quit: Gettin' stinky!]
sdutt has quit [Ping timeout: 480 seconds]
<jenatali>
Huh, my tessellation series has isoline flakes. That's fun
<zmike>
I think I got those with zink too if you're on sw
<jenatali>
Yeah the CI runs on WARP/software
FireBurn has joined #dri-devel
craftyguy_ is now known as craftyguy
nchery has quit [Ping timeout: 480 seconds]
mszyprow_ has joined #dri-devel
Bennett has quit [Remote host closed the connection]
pnowack has quit [Quit: pnowack]
<FireBurn>
There's seems to be a regression on Navy_founder in a recent Mesa commit - bisecting now
<FireBurn>
I'm going to guess one of the alignment patches
<FireBurn>
for Radv
tursulin has quit [Ping timeout: 480 seconds]
mszyprow_ has quit [Ping timeout: 480 seconds]
<FireBurn>
First bad commit ef40f2ccc29ba7031bcb4ef100f8a9d290df9689
<airlied>
bnieuwenhuizen: ^
FireBurn has quit [Quit: Konversation terminated!]
ngcortes has joined #dri-devel
FireBurn has joined #dri-devel
nchery has joined #dri-devel
sdutt has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
FireBurn: regression doing what?
<FireBurn>
Running any vulkan app
<FireBurn>
vkcube for example
<FireBurn>
system freezes up until the dGPU is reset
ngcortes has quit [Remote host closed the connection]
<FireBurn>
This is on a prime system renoir & navy_flounder
<bnieuwenhuizen>
Ok
<FireBurn>
It would render fine on renoir if I forced that card
<zmike>
mareko: are you planning to get that sparse texture clamp MR in this week?
nchery has quit [Quit: Leaving]
sdutt has quit [Read error: Connection reset by peer]
jewins has quit [Ping timeout: 480 seconds]
mripard_ has joined #dri-devel
bbrezill1 has joined #dri-devel
bbrezillon has quit [Ping timeout: 480 seconds]
mripard has quit [Ping timeout: 480 seconds]
<HdkR>
Spooky. Link training failed when my displays were coming back online.
<HdkR>
"[drm] enabling link 2 failed: 15"
<HdkR>
disabled the panel with arandr then reenabled and it was fine :|
<clever>
HdkR: i think that was mentioned in a recent LTT video, about how DP cables can be poorly made and not meet the specs, and link training will dynamically fallback to a slower speed, often without the user even noticing
<clever>
which can make diagnosing issues difficult, when it randomly goes away
<HdkR>
It is very unlikely that this is a cable issue
<HdkR>
fiber doesn't age quite the same as copper :P
<airlied>
fiber converter issue? :-P
<HdkR>
Could be transceiver issue yea
<HdkR>
Hopefully not though
<clever>
or the cables between the connector and the transceivers?
<clever>
HdkR: and there are wires between the pins of the connector, and the transceiver chip
<clever>
which may just be pcb traces
<clever>
but that could still have design problems?
<HdkR>
I'd claim that's just tranceiver failure at that point
oneforall2 has quit [Remote host closed the connection]
<clever>
yeah
<vsyrjala>
you guys are overthinking this. step 1) blame some firmware
<HdkR>
Yea, I upgraded my kernel from 5.13 to 5.16.2 last week. I'd blame that far before I blame the cable itself.
<HdkR>
Also, I was semi-hoping that I'd have working DSC in the version upgrade. Didn't happen, sad times
oneforall2 has joined #dri-devel
<anholt>
gagallo7[m]: hope I've got the right person here. do you know by chance why the current CI skqp is running some unitTest_Vk tests, and us in #freedreno have failed to get those to run with a command line like "./skqp <assetsdir> '' results/unitTest unitTest_Vk" (using the binary out of CI's rootfs)
<anholt>
imirkin: no luck with finding anything with asan on skqp on your branch, btw.
<imirkin>
o well
fxkamd has quit []
Duke`` has joined #dri-devel
idr has quit [Quit: Leaving]
aruna has joined #dri-devel
aruna has quit []
aravind has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
famfo has joined #dri-devel
mszyprow_ has joined #dri-devel
itoral has joined #dri-devel
tzimmermann has joined #dri-devel
mbrost has quit []
mszyprow_ has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
mattrope has quit [Read error: Connection reset by peer]
mlankhorst has joined #dri-devel
ahajda has joined #dri-devel
mattrope has joined #dri-devel
mattrope has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mszyprow_ has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
danvet has joined #dri-devel
mbrost has joined #dri-devel
Major_Biscuit has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
macromorgan is now known as Guest635
macromorgan has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
Guest635 has quit [Read error: Connection reset by peer]
itoral_ has joined #dri-devel
tursulin has joined #dri-devel
cphealy has quit [Ping timeout: 480 seconds]
itoral has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
heat has quit [Remote host closed the connection]
cphealy has joined #dri-devel
pcercuei has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
* tzimmermann
thinks we're doing a miserable job at promoting drm
<javierm>
tzimmermann: I thought the same. AFAICT writing DRM drivers is much more simpler due all the helper functions that exist
<tzimmermann>
javerm, i guess you read andy's response. he says that drm is too complex. but in reality, it reflects the nature of today's hardware and with all the helpers, writing a drm driver is not harder then fbdev.
<tzimmermann>
i'm not blaming him. our marketing probably isn't good
gawin has joined #dri-devel
* danvet
types a lament
<javierm>
tzimmermann: yes, I was referring to andy's comment indeed
<javierm>
and not blaming him either. I think it's a perception issue
<danvet>
yeah I get that it's overwhelming
<danvet>
sure we have helpers for everythign
<danvet>
and they can be coaxed into doing a lot of things
<danvet>
but also ... we have helpers for everything, and they can do so much stuff
<danvet>
also dri-devel is a firehose
<danvet>
and the more collaborative commit rights style is nice for regulars
<danvet>
but for new contributors I guess it's just a lot more chaos and not a clear contact person for their problem
<danvet>
but still, "let's keep writing shitty verbose drivers for an uapi everyone actively abandons" can't be the answer
<tzimmermann>
danvet, im not blaming you either
<danvet>
tzimmermann, nah no blame, just agreeing with you all on this
<danvet>
well I don't take the "way too complex"
<danvet>
with that reasoning no one should port their driver to linux, period
<danvet>
because linux device driver support is definitely way too complex
<tzimmermann>
in my experience, there's a significant learning curve when going from fbdev's 'ioctl+mmap' to drm's atomic state updates. i think that's what holds people. once you 'get drm', it's no big deal. i don't know how to improve this situation
<pq>
Documentation.
mvlad has joined #dri-devel
<danvet>
yeah the abstraction between the simple pipe helpers and how that maps to fbdev is kinda big
<danvet>
pq, yeah, but also good docs are hard :-/
<tzimmermann>
pq, we do have docs. simple pipe is also nice. still...
<pq>
You'd have to work with someone who is an oldschool fbdev developer who knows nothing about KMS, let him ask all the questions and write a story that answers those questions without being a Q&A but more like an introduction and a cook book.
<pq>
definitely a lot of work for both of the people involved
<pq>
Like, starting from how does userspace work when it uses atomic KMS.
<pq>
how that translates to what a driver interfaces with
<pq>
It'd be written like a book, and not like a programming reference manual.
<tzimmermann>
pq, indeed. it comes down to someone needs to write a book
<pq>
so we know what would help, but can anyone spare the effort to make it happen?
<pq>
The alternative to writing a book is to write those new drivers oneself, and letting the oldschool fbdev developers do the testing and hardware interfacing.
<pq>
Which one is less effort? And would the book become uselessly outdated too soon?
* GyrosGeier
wonders if I could use Vulkan without X or Wayland if I don't need windows
<daniels>
GyrosGeier: yep
<javierm>
pq, tzimmermann: bootlin folks had really nice intro material to DRM/KMS
pnowack has joined #dri-devel
<pq>
javierm, cool, anyone posted links to that? :-)
pnowack has quit [Remote host closed the connection]
<tzimmermann>
pq, i don't think there are really many ppl who use these old drivers. otherwise they would have shown up already. the few that stil use it are persisten though...
pnowack has joined #dri-devel
<tzimmermann>
pq, for a book effort. i'd guess it would take 2 yrs and then only last 2yrs years. the overall concepts are stable, but the helpers change constantly.
<pq>
tzimmermann, sure, but if one wants those old drivers gone...
<pq>
I suspect even an overview of the concepts might help.
<danvet>
yeah there's plenty of good and generally up-to-date drm-intro talks
<danvet>
maybe we should link them and keep that updated in the docs?
<pq>
Don't these people just reject DRM outright without bothering to even try to figure out what it's about, because there is too much code in it and code is maybe all they know to read?
<pq>
in short, prejudice
<danvet>
pq, I do get some "get of my lawn" feels from these discussions
<danvet>
which is why I want to gently but firmly put down the hammer on at least adding new drivers and features to fbdev
<javierm>
pq: yes, I think is more of a perception problem. DRM/KMS is seen as a more feature rich uAPI / subsystem, hence writing drivers for it should be more complex
<danvet>
since 6 or so years (when tomba stepped down as last active fbdev maintainer) consensus among people who actually write display code in upstream is that it's drm, not fbdev
<pq>
FYI, when I've been following these discussion, I do not remember a single time anyone would have replied with links like javierm's above. But maybe I just forgot?
<danvet>
javierm, want to write a doc patch to add these kind of talks in a section somewhere (maybe in the intro)?
<javierm>
danvet: sure
<danvet>
I think as long as we include the year and a short summary and keep them in revers chrono order this should be really useful
<danvet>
and maybe ping the usual suspects here for more links
Lucretia has joined #dri-devel
<danvet>
I think pinchartl also has made some good overviews
<danvet>
daniels might have some good intro blogs from collabora
<danvet>
maybe we could also link to the fd.o planet
<danvet>
and perhaps the last few xdc programs
<javierm>
danvet: agreed. I'll search tonight for the talks and post an RFC. People can answer in the patch with suggestions fore more talks / docs / links
<danvet>
to make these things more discoverable
<danvet>
javierm, awesome, thx a lot
<javierm>
danvet: yw
<pq>
javierm, might be good to suggest an order of reading too, because one open "an intro" and it's 200 slides, they probably just close it without reading, being even more convinced that DRM is too complicated.
<pq>
*if one opens "an intro"
<javierm>
pq: indeed
<danvet>
yeah 1-2 sentences what it contains and what it's good for would be good
<javierm>
I don't understand the claim that DRM is not suitable for certain (old) hardware. It's just software, everything could be extended
<javierm>
or maybe I'm missing something due my DRM/KMS ignorance
<tzimmermann>
here we go again...
<tzimmermann>
it's not your ignorance
<javierm>
tzimmermann: that's what I thought. It seems the claims are just false
<tzimmermann>
but how do you explain that
mclasen has joined #dri-devel
jljusten has quit [Quit: WeeChat 3.4]
<DPA>
"I don't understand the claim that DRM is not suitable for certain (old) hardware." I think that may have todo with 2d acceleration. I think there was something about that not getting an abstraction somewhere (mesa/drm), but I don't remember exactly.
cphealy has quit [Ping timeout: 480 seconds]
cphealy has joined #dri-devel
<vsyrjala>
there is no acceleration with fbdev either
<pq>
not for userspace, but there used to be acceledation for fbcon, and fbcon accel is what they care about
<pq>
there are no any public interfaces (or their lack of) in question here, since it's all about fbcon. Not even fbdev.
<vsyrjala>
nothing prevents a drm driver from implementing the fbcon accel hooks
<vsyrjala>
i've occasionally pondred about doing it for i915. but then i remember that i'd rather like to have a working console when both the gpu and wifi are dead
<pq>
that's what seems very hard to tell people, it just comed to "too complicated with DRM"
<pq>
which, if there really is not a single example of actually implementing those, is kinda hard to rebut
<tzimmermann>
pq, didn't we have that at some point?
<tzimmermann>
we removed a few for simplicity
<pq>
I have no idea, but the discussion seemed to indicate they don't exist upstream.
<pq>
were those with real GPUs of the 2D accel things of the 90s?
<pq>
*or
<vsyrjala>
real gpus have blitters ;)
<pq>
if real GPUs, then I bet it looks really complicated - it's all about the appearances, how easy it looks
<tzimmermann>
i haven't looked closer, nouveau has some. vmwgfx. gma500 used to.
<tzimmermann>
with generic fbdev emulation, there's only cpu memcpy. but even that code could get the driver callbacks if necessary
<DPA>
I heared somewhere that fbdev if faster than rockchip drm on Xorg. I haven't verified it myself, but on the ppp with DRM, some things are slow in a way which just feels wrong. Like, I resize xeyes without a compositor, and something about how it synchronizes the redraws & redraws stuff on every expose events almost hangs the whole server.
<pq>
"could", "should", etc. hypotheticals don't seem to convince the people
<tzimmermann>
DPA, no one shows up to improve the situation. it's not like we're sending anyone away
<DPA>
I wouldn't even know how to debug something like this.
<tzimmermann>
i'm not blaming you, sorry
<pq>
No-one takes the plunge, because it looks too hard, because there are no existing examples and those examples that existed were removed "because of simplicity".
<pq>
How is that not saying "it's going to be really complicated with DRM"? ;-)
<tzimmermann>
pq, i get your point. but several of fbdev's proponents don't even seem to be interested in learning
<pq>
yeah, that's possible too, and probably unfixable - at least until there appears one driver that does it
<DPA>
There are things I like a lot about fbdev. Like, it's kind of per monitor/output, rather than per card. And I don't need root to do any modesetting. And I can just paint an fb some color with "yes $'\x01\xff\x01' >/dev/fbX".
<DPA>
I don't think DRM can be changed to be more like that again anymore, can it? Not because it's not technically possible, but because the uapi probably shouldn't change that strongly?
Lucretia has quit []
<pq>
DPA, you don't need any root to modeset on KMS either. The "DRM master" concept is different, and you can get it just by being the first one to open device.
devilhorns has joined #dri-devel
<tzimmermann>
DPA, i see what you mean. fbdev is closer to the 'traditional model' of a user's terminal. fbdev has a different concept of video memory: it gives you access to raw bytes (or something very similar). this really only works well if there's a single program (e.g., fbcon, x11) that uses the memory. drm abstracts memory into buffer objects. that is required by modern userspace and hardware. even drm's fbdev emulation is
<tzimmermann>
backed by a buffer object. we could do modeset in drm via 'fbset', but no one cared much, so it doesn't exist (or only on VMware graphics)
Lucretia has joined #dri-devel
gawin has quit [Quit: Konversation terminated!]
<DPA>
I'm sure this could all have still been more closely represented / mapped to different files / regular file semantics. If I can do things in bash, I consider them simple.
<javierm>
that comes with a SSD1306 chipset and that's only supported by one of the drivers in staging
itoral_ has quit [Remote host closed the connection]
jljusten has joined #dri-devel
<daniels>
danvet: I'm afraid I don't have any good blogs to hand
<daniels>
the best ones I know of are the bbrezillon/paulk ones linked above
<danvet>
pq, it's more because of robustness
<danvet>
accelerated fbcon is a lot more fragile, so when it's the only thing that can show you an ooops
<danvet>
you really don't want it
<danvet>
the other thing is that doing a competent acceleration which is fast is hard
<alyssa>
vroom vroom
<danvet>
and the kernel is kinda the wrong place for those, at least when you have a big gpu
<danvet>
and blitters tend to suck a bit for painting characters
<danvet>
at least when it's lots of characters
<danvet>
also for debug you want immediate mode everything
<danvet>
which is exactly not the thing you want for speed
<pq>
danvet, sure, but they are not talking about big gpu. :-)
<danvet>
pq, oh I just meant this is why none of the big gpu driver fbcon accel backends in drm got merged or at least unmerged
<danvet>
we had some
<danvet>
heck we still do have some
<danvet>
gma500 with pte rewriting for accelerated scrolling as an example
<pq>
is it anything you dare point at as an example?
<danvet>
no
<danvet>
I mean I don't dare pointing anyone at the fbcon accel code either
<danvet>
the thing is a classic midlayer mistake
<pq>
to me it seems like having just one good example of a DRM driver doing fbcon Right(tm) for one 90s gfx card, even without any accel, could go a long way.
<danvet>
well there's a bunch of things missing even in the generic fbdev emulation
<danvet>
e.g. modesetting support
<danvet>
bunch more pixel formats
<danvet>
given that no one bothered typing that for 10+ years I just don't see the demand
<danvet>
and you really need modesetting for your 90s gpu
<pq>
sure, lacking those don't help your side of the argument :-)
<danvet>
assuming it's connected to a 90s CRT too :-)
<danvet>
pq, well we also didn't have tinydrm until a few years ago
<danvet>
but yeah it's not that drm is perfect
<danvet>
I did ponder adding i915 gen1 support and the vga register helpers those would need years back
<danvet>
just never seemed like worth the trouble
<danvet>
I still have the box collecting dust somewhere, no idea whether the capacitors are still any good
<mlankhorst>
atomic on your i915
<ajax>
atomic on old gpus is ~trivial
<ajax>
only one crtc! with like no features!
jewins has joined #dri-devel
<ajax>
so like, most of the xf86 drivers for that era of hardware are just the vgahw layer, which already has an abstraction for whether the vga regs are in io or memory bars
<ajax>
you could handle just about all of the legacy drm devices that way, tdfx and savage and friends
<ajax>
would be an excellent project for a newbie, assuming they can find a pci card or an agp mobo
<ajax>
where by "old" here i mean pre-dx8 or so
<mlankhorst>
That's the real challenge, assuming they have such hardware. :)
<mlankhorst>
Would a 32-bits machine even boot, still?
Bennett has joined #dri-devel
<danvet>
yeah with a neat vgahw helper and the bridges for tv out encoders and stuff it should result in some tiny neat drivers
<danvet>
mlankhorst, yeah that still works
<danvet>
I think you need an og pentium by now for latest kernels
<danvet>
oh maybe it was only debian that moved to 686 or so?
<ajax>
might be. fedora doesn't have a 32-bit kernel anymore but when it did it'd been i686+ since i wanna say fedora 20 or so
<ajax>
and i think pthreads started requiring working cmpxchg at some point
<ajax>
not like you care a lot about atomicity on your single core of 486
<ccr>
there's always good 'ol Slackware tho, it claims to run on 486
<daniels>
ajax: can't help but feel you'd be better off running a 486 emulator on a Cortex-M
fxkamd has quit []
<daniels>
for the power budget, you could in fact have a beowulf cluster of them
fxkamd has joined #dri-devel
<ajax>
daniels: if you can get one with pci slot, almost certainly, yes.
<ajax>
"better off" is doing a lot of work there tho
<imirkin>
ajax: but where will you find one with EISA
<ajax>
la la la can't hear you. my this-tall-to-ride bar has been pci since before m12n
<imirkin>
i guess no MCA for you either then
<ajax>
(which has since moved to "must know what an alpha channel is", and then "plausibly capable of gles2")
<ajax>
src/gallium/drivers/verite
ella-0 has joined #dri-devel
<zmike>
why doesn't fedora package deqp-runner? 🤔
ella-0_ has quit [Read error: Connection reset by peer]
<ajax>
hmm, don't think i've tried to package anything rust for us yet
sdutt has joined #dri-devel
<kisak>
is it actually worth the overhead of a distro-maintained test suite? I expect you're going to always want something newer than the package maintainer
<ajax>
the thing about working on a distro for your day job is you get to define what the maintainer wants
<javierm>
ajax, zmike: I did some rust packaging in Fedora and it's actually quite straightforward with rust2rpm
<javierm>
most of the spec file is autogenerated from the crates.io metadata
mbrost has joined #dri-devel
mbrost has quit []
mbrost has joined #dri-devel
mattrope has joined #dri-devel
cworth has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
<mareko>
zmike: not sure
JohnnyonFlame has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
Haaninjo has joined #dri-devel
nchery has joined #dri-devel
Duke`` has joined #dri-devel
fxkamd has quit []
frytaped has joined #dri-devel
gawin has joined #dri-devel
frieder has quit [Remote host closed the connection]
iive has joined #dri-devel
frytaped has quit [Quit: frytaped]
Akari has joined #dri-devel
jewins has quit [Quit: jewins]
Akari` has joined #dri-devel
ybogdano has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
<ajax>
zmike: the answer seems to be partly that there's at least three other crates i'd need to package first
<ajax>
which isn't a _problem_, necessarily, just a thing
<cheako>
".18_" is 7FPS, while ".26_" is 24FPS.
gouchi has joined #dri-devel
<zmike>
ajax: not ideal though given how overworked you are
<cheako>
Crucially when I run qrenderdoc, from Debian testing, it exists with instruction something or another.
<ajax>
zmike: nod, not a priority here at all, just figured i'd take a shot in case it was trivial. i'll see if i can bootstrap things into a copr at least
<zmike>
mainly just curious because cargo has historically never worked on any of my machines
<zmike>
so getting an updated deqp-runner is annoying
mlankhorst has joined #dri-devel
tarceri has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
phomes has joined #dri-devel
fxkamd has joined #dri-devel
<cheako>
zmike: There are rust docker images?
<cheako>
I think rust has some issues, but I didn't know it was just not working for ppl.
phomes has quit []
ahajda has quit []
<jekstrand>
robclark: Any recommendations for doing cross-builds on Fedora?
<jekstrand>
I need to figure out how to build panfrost etc.
<robclark>
hmm, I always just build natively on device
<robclark>
(other than kernel)
<robclark>
so haven't really gotten around to messing with meson cross build file stuff
<danylo>
I build mesa/deqp-vk with jhbuild
<jekstrand>
This is all aparently fairly easy on debian but I really don't want to become a debian user
<idr>
jekstrand has standards. :)
<imirkin>
jekstrand: fairly easy on gentoo as well
<ajax>
jekstrand: i think it's something like `dnf --forcearch aarch64 --destdir /usr/qemu-aarch64 install whatever` and then install qemu-aarch64 and the cross gcc tools
<ajax>
but i've not tried in a long time
<javierm>
jekstrand: if you want to build the srpm then something like `fedpkg mockbuild --mock-config fedora-35-aarch64` should work
<ajax>
alternatively if you can wrap what you want to build in an srpm, mock(1) has a --forcearch that works
<jekstrand>
javierm: I don't want to go through srpm. Maybe I should just grab an aarch64 image and extract it somewhere.
<ajax>
(builds a chroot and runs the whole thing under emulation, rather than cross building)
<jekstrand>
Running under emulation may be ok. I'll experiment some.
<ajax>
but yeah if you can qemu an image and "native" build inside that it's probably a lot less fiddly
<ajax>
native-under-emulation builds are like ~10x slower in my experience, which isn't awful
<jekstrand>
Or I may be able to build locally with a sysroot flag
<javierm>
yeah a VM with qemu-system-aarch64 and "native" builds is probably less trouble
<jekstrand>
And use the native x86 tools but against the image.
<javierm>
ajax: which is still faster than native build on a rpi4 :)
<imirkin>
jekstrand: did you have to give up your 96-core build superpowers?
<ajax>
javierm: given enough thrust, pigs fly just fine...
<jekstrand>
imirkin: Planning not to. :)
<jekstrand>
I just have to figure out how
<imirkin>
hehe
<imirkin>
"oops, i lost it"
<jekstrand>
Running in emulation but kicking everything to icecream may be the plan.
<jekstrand>
It'll link in emulation which will suck but otherwise be ok
<jekstrand>
First, I need to get icecream and firewalld to stop fighting
<imirkin>
jekstrand: fwiw i have an arm "chroot", and use native cross-gcc to build against that. works great.
<jekstrand>
imirkin: That's what I'm thinking
<imirkin>
the arm chroot was created using gentoo's crosstool, but i bet you can install random-other-arch's packages to a chroot in redhat/debian too
<jekstrand>
I can rsync from the SD card I've got in my pi4 to get myself a chroot.
<imirkin>
(i know you can definitely install packages in centos under a chroot, but i've only ever done it for same-arch)
<ajax>
dnf --forcearch --destdir, yeah
<imirkin>
jekstrand: well, the trouble becomes that you need e.g. a new libwayland.so etc
<imirkin>
so you need a way to "maintain" the chroot
<jekstrand>
That's what qemu is for.
<daniels>
(you do not need a new libwayland.so btw)
<imirkin>
daniels: sometimes you do.
<jekstrand>
I've not done it in a long time but you can set up kernel hooks to automatically qemu any ARM binaries. Then you just chroot into it and run the update tool.
<imirkin>
and i just picked on that as a random dep. other deps need bumps too.
<ajax>
jekstrand: i'm reasonably sure that, if you install qemu-user.rpm, those get set up for you
<jekstrand>
:+1:
<imirkin>
jekstrand: sounds like you can just use that dnf command that ajax gave you to maintain it directly?
<jekstrand>
I've not done any serious ARM dev in 12 years so...
pendingchaos has quit [Read error: Connection reset by peer]
<imirkin>
daniels: my point was "you need to be able to dump deps so a fixed chroot isn't a great idea", i didn't mean to pick on a specific dep :)
<daniels>
yeah, 100%
<daniels>
ajax: does that have the static bins on fedora?
<ajax>
... i wonder if i could get toolbox(1) to make an other-arch container. that'd rule.
<ajax>
daniels: i don't know what you mean by that?
<imirkin>
ajax: that's basically what crosstool lets you do on gentoo. instead of running "emerge", i run "foo-arch-emerge", and it cross-builds stuff into a diff prefix with a completely separate config.
<daniels>
ajax: statically-linked versions of e.g. qemu-system-aarch64
<daniels>
ajax: since you're going to have a bad time if you're chrooted into an aarch64 sysroot, but in order to run qemu-system-aarch64 you need to resolve x86-64 dylibs
<ajax>
oh right
<ajax>
yeah so that's the qemu-user-static package apparently
<daniels>
(though istr there is a binfmt-misc flag which tells it to resolve from the root mount ns rather than from ctx)
<imirkin>
no qemu involved at all in my case
<ajax>
(user, not system)
<daniels>
ajax: er, yeah
<daniels>
jekstrand: but yeah, generally it's: 1) build your rootfs somehow (debootstrap on Debian, looks like mock on Fedora), 2) install qemu-user-static & enable binfmt-misc so you can chroot into your rootfs and screw around with it as if it were native, 3) install the cross-compilation toolchain so you get e.g. aarch64-linux-gnu-gcc to run on x86-64, 4) write a meson cross-file which gives it the path to those tools & relevant params
<javierm>
daniels: yeah, for (2) install qemu-user-static already ships some /usr/lib/binfmt.d/qemu-aarch64-static.conf that makes it work automagically
<daniels>
neato
pjakobsson_ has quit [Remote host closed the connection]
pendingchaos has joined #dri-devel
MajorBiscuit has joined #dri-devel
<ajax>
does anyone actually _want_ OML_swap_method
<austriancoder>
jekstrand: I do all my crossbuilds in a docker container. On e.g. the gc2000 dev board I boot Debian via NFS and mount my the crossbuild folder from my x64 host at ~/shared and with some magic I can do ~/bin/mesa-armhf-debug APP. Compiling on the device is too slow for me.
<ajax>
'cause like... i don't think it works.
<austriancoder>
oh.. i switched to podman some months ago.
* austriancoder
has a to-do item to write a blog post about my dev setup. I am using debos to create the rfs used for the devices. I like to have everything versioned and reproducible.
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jekstrand>
Well, I've got a root image. Now to figure out why dnf won't run in it. :-/
tzimmermann has quit [Quit: Leaving]
devilhorns has quit []
tarceri has joined #dri-devel
<kisak>
eric_engestrom: would you happen to have a note for why Revert "nir/algebraic: distribute fmul(fadd(a, b), c) when b and c are constants" was denominated? CI checksum noise in the patch?
mszyprow_ has quit [Remote host closed the connection]
mszyprow_ has joined #dri-devel
ngcortes has joined #dri-devel
<eric_engestrom>
kisak: I think that was a mistake and same thing for 1b88777e97f635612c56
<eric_engestrom>
I must have denominated them by accident, and I never question myself for some reason
<zmike>
same
<eric_engestrom>
thanks for asking!
<eric_engestrom>
I just cherry-picked it and indeed the hashes will need to be updated, which I'll try doing but otherwise I'll ask on the MR
<kisak>
thanks for re-evaluating
<eric_engestrom>
sure thing! I'll try to take a second look at anything I've denominated before making a release to make sure it wasn't done by accident
orbea has quit [Remote host closed the connection]
orbea has joined #dri-devel
<HdkR>
azxcas
<HdkR>
oop. Linode network problem.
kem has quit [Ping timeout: 481 seconds]
sdutt has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
mlankhorst has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
Anorelsan has joined #dri-devel
Anorelsan has quit [Quit: Anorelsan]
nchery has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jenatali>
Ugh xfb is awful
<ajax>
it's amazing how many bad versions of "make the gpu compute the thing" we went through before getting to "make the gpu compute the thing"
Bennett has quit [Remote host closed the connection]
<ajax>
jenatali: btw impressive work on d3d12 tess, that's an unenviable set of constraints you're working with
<jenatali>
Thanks
<jenatali>
It's not perfect, but it's most likely good enough for real-world use cases
<jenatali>
My struggle right now is DrawTransformFeedback: D3D stores buffer sizes, not vertex counts, so I need a stride to convert them, and I'm failing to find a good way to get that at DrawTransformFeedback-time
<imirkin>
jenatali: iirc hw does the same thing
<imirkin>
thankfully hw also has a special "draw transform feedback" which also takes bytes on input :)
<imirkin>
(at least that's my recollection. i try to never look at that stuff)
<ajax>
afaict hw does enough to implement whatever d3d specifies and then gl is the converged generalization of what hw actually did
<jenatali>
Oh looks like in 11on12 I just used the VB stride... maybe that'll be good enough
<jenatali>
It was like 8 years ago that I wrote my last iteration of DrawAuto lol
jfalempe_ has joined #dri-devel
jfalempe has quit [Read error: Connection reset by peer]
pnowack has quit [Quit: pnowack]
danvet has quit [Ping timeout: 480 seconds]
<jekstrand>
Oh, DrawTransformFeedback...
<jekstrand>
That's gonna be fun and I'm sorry.
<jekstrand>
You may need to transform it in a shader.
<jekstrand>
Depending on what D3D12 provides
<jenatali>
As long as this stride is right it should be fine
<jenatali>
Yeah that's what I did in 11on12 and what I was planning to do here. And is why compute came before GL4.0 for me :)
<jekstrand>
Intel HW does something that's convenient enough for D3D12 and OpenGL but not Vulkan so we have to implement division on the command streamer for Vulkan.
<imirkin>
ouch. division sounds painful.
<imirkin>
and i was annoyed about having to implement multiplication...
<imirkin>
not sure how i'd be able to express my feelings about having to implement division :)