01:14 dcbaker: kallisti5: you can have my r-b on the meson patch (sorry I'm in my phone so I'm not logged into gitlab)
01:19 kallisti5: dcbaker: thanks! I could have extended it to fp64 as well... but I think the chances of that conflicting on any platform are a lot less likely
01:22 kallisti5: ^^ ignore. 'meson patch' I'm losing my marbles
01:22 kallisti5: i'll add your r-b. Thanks :-)
01:28 dcbaker: Np
01:31 minicom: hi, I've a question about (vintage, these days) X.org drivers like xf86-video-neomagic. They have XAA for 2D accel, how should that be done in modern drivers? XAA was dropped from X.org some years ago, so the accel part can't be utilized with a modern graphics stack, the Linux kernel only contains a slow fbdev driver. GLAMOR doesn't seem useful for
01:31 minicom: this kind of 2D-only hardware, or is it? EXA doesn't seem to have a good future either.
01:54 airlied: minicom: most modern apps don't get any advantage from the acceleration on those older gpus
01:54 airlied: so are better served by a shadow framebuffer setup
01:59 minicom: airlied: I guess, but some do. Like, moving windows around in a window manager
02:01 airlied: minicom: not really
02:01 airlied: minicom: like you need a complete really old system to make the accel useful
02:02 airlied: the world has moved on to composited desktops, and supporting accel for the old case of non-compositied isn't really where things are being worked on
02:05 minicom: I see. I still have some of those old systems, I guess I'm stuck with old X.org releases then, if I want any 2D acceleration.
02:06 keithp: minicom: getting exa acceleration working would be a pretty straightforward effort
02:06 keithp: you'd then have a usable system without compositing
02:06 airlied: as long as you don't browse the web :-P
02:07 keithp: airlied: meh? exa makes window moving and scrolling plausible at least
02:07 kallisti5: minicom: lol. While Haiku doesn't have 3d hardware acceleration yet... we have 2d acceleration in a few cards
02:07 kallisti5: minicom: it's completely useless
02:07 airlied: keithp: exa without the render hook?
02:07 keithp: airlied: definitely
02:08 keithp: everything draws client-side these days anyways; render isn't going to help much
02:08 airlied: I suppose if you only have exa ops with the front buffer on the gpu, and between the frontbuffer
02:08 keithp: yeah, the key is FB->FB blt
02:09 keithp: otherwise you're using the CPU to read from the card, which is painful for window moving
02:09 airlied: you just don't want any other surfaces on a card with that much vram
02:09 keithp: yup
02:09 airlied: keithp: not with shadowfb :-P
02:09 keithp: airlied: a fine point; whether shadow will be faster depends on how bad the CPU is, and how slow writes to the card are
02:09 airlied: then you get to saturate the pci bus :-P
02:09 keithp: "PCI".
02:09 keithp: could well be ISA :-)
02:10 kallisti5: Vesa Local bus maybe
02:10 keithp: sweet!
02:10 keithp: AGP
02:10 keithp: all the awesome busses
02:11 kallisti5: I was so pumped when I got a VESA Local Bus video card on my 486
02:12 keithp:was sad to get a Sun machine with accelerated graphics as the FB was so much slower from the CPU
02:13 kallisti5: oh.. if you have any Sun hardware hanging around, someone is porting Haiku to SparcStations
02:13 keithp: kallisti5: this was in 1990
02:13 keithp: my sun box hasn't booted in almost 20 years
02:14 kallisti5: https://download.haiku-os.org/nightly-images/sparc/ if you feel like booting it up :P
02:14 keithp: absolutely no thanks
02:14 ccr: :D
02:14 kallisti5: lolol
02:14 keithp:has plenty of hobbies
02:14 ccr: I somehow read that as "nightmare-images"
02:14 keithp: ccr: probably not far off
02:15 kallisti5: Fair. I've been balancing working our arm,arm64,and riscv64 ports... all the assembly blends together after a while
02:15 keithp:tries to accept other peoples hobbies ...
02:15 keithp: yes it does
02:20 kisak: you can find a non-composited DE fairly easily, but it's hard to find something productive to do on those old systems to justify the effort
02:21 keithp: sure, xfce is a fine DE for any machine
02:21 keithp: but, without a modern browser ...
02:22 tehcloud: lynx
02:23 minicom: keithp: thanks for the suggestions, I'll try to look into adding EXA
02:24 minicom: kisak: as a hobby I've collected quite some 20+ year old ThinkPads :-)
02:27 kisak: and they're all crying out to have PrBoom played on them :P
02:29 kisak: and maybe Aleph One?
02:29 tehcloud: zsnes
03:04 dcbaker: Ah zsnes, finally I've found a reason to get out my old think pad t23 and remember the days when s3 wasn't just a patent troll
03:37 bl4ckb0ne: how long does it take to compile mesa on the t23
03:55 dcbaker: I don't even want to know 1ghz Pentium 3, lol
03:56 dcbaker: But it's gonna be an old Mesa. The s3 driver was dumped after Mesa 7 IIRC
04:03 bl4ckb0ne: wew that was 13 years ago
04:07 bl4ckb0ne: cant find the release note
04:07 bl4ckb0ne: but i dont have any pentium3 motherboard laying around anyway
04:07 HdkR: Time to stick a Pentium 3 in to mesa CI? :D
04:09 bl4ckb0ne: i wonder how many pentium 3 are in use atm
04:11 airlied:wondesr if my pentium m switches on anymore
04:12 bl4ckb0ne: i have a ziplock bag full of cpus somewhere in a box, i wonder if they turn on too
04:22 airlied: kusma: why does the stencil fallback do 8 instance draws?
05:32 jenatali: airlied: 1 per bit if I'd have to guess?
05:36 airlied: jenatali: it already loops 1 per bit
05:36 jenatali: Nevermind then :)
05:36 airlied: it does 1 call of 8 instances in a loop 8 times :-P
05:36 airlied: seems excessive, works where I wanted to use it with 1 instance anyways
05:38 airlied: though the call to clear depth stencil is tricky since that could cause a reenetrant u_bliter access
11:56 pendingchaos: dcbaker: was there supposed to be a list of patches in this email: https://lists.freedesktop.org/archives/mesa-dev/2020-December/224797.html ?
14:51 dcbaker: Yes there was, doh
14:52 dcbaker: There were two v3dv patches, a radv patch, and an aco patch, off the top of my head. Maybe a.freedreno patch as well
14:53 dcbaker: I'll send out an updated email
15:14 dcbaker: pendingchaos: thanks, and sorry about that. I've sent out a follow-up email
21:03 DPA: The UDL driver really doesn't like the way I want to use it.
21:03 DPA: I'm using it as second device in Xorg with the modesetting ddx, the first one uses etnaviv + kmsro.
21:03 DPA: I've set 'Option "AccelMethod" "Off"' in xorg.conf, but only for the udl device, that makes the modesetting ddx allocate a dumb bo instead of using the whole glamor stuff,
21:03 DPA: and passes it directly to the other/first modesetting ddx instance, which does import it and does render to it with glamor. It's basically the same kmsro would have done anyway,
21:03 DPA: but avoids some copying textures around Xorg/glamor would otherwise do. UDL doesn't like it though, I get this stack trace: https://pastebin.com/nzuY7jZt
21:03 DPA: It does show the first frame after a modeset, but it doesn't update the screen aside from that.
21:03 DPA: I also found this suspicious TODO, is it related to my problem? https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/udl/udl_modeset.c#n305
21:08 anholt: minicom: I would really recommend not working on exa. you really do just want a shadow framebuffer.
21:10 anholt: shadowfb means everything is fast enough. exa means that some things are a bit faster, and other things are catastrophically slow.
21:38 minicom: anholt: hmm, the existing driver seems to already have shadowfb support. Is EXA mutually exclusive to shadowfb?
21:43 anholt: you could make something one might call shadowfb using exa, but that would miss the point ("you really don't want to use exa")