11:21ask6155: hello. how are gpu fan speeds controlled?
11:24RSpliet: At long last...a new monitor
11:25pmoreau: \o/
11:25RSpliet: Shame it doesn't work well with nouveau/kernel 5/11
11:25RSpliet: *5.11
11:26pmoreau: If only you had some experience hacking on Nouveau… 😉
11:26pmoreau: Though I’m guessing time might be a big issue.
11:26RSpliet: I was prepared for how my GT640 doesn' support its native resolution, but nouveau/drm seems to do a really poor job at not exposing unsupported resolutions. GDM/Wayland and GDM/X.org tries to drive it at 2880x2160... I've also seen my monitor report sth like 2992x2160
11:26RSpliet: I suspect it's just trying to cram 4K through the cable, and it doesn't work :-D
11:27fling: sneaky
11:27RSpliet: (although it seems to work for VTs)
11:28pmoreau: BTW Roy, you might know the answer to ask6155’s question: “how are gpu fan speeds controlled?”.
11:28RSpliet: pmoreau: I don't actually :-D That was mupuf's expertise
11:28pmoreau: My bad
11:29RSpliet: No worries
11:29RSpliet: Anyway, there's two issues:
11:29RSpliet: 1) Nouveau shouldn't be pretending it supports modes that it doesn't
11:29RSpliet: 2) GDM should honour the monitors.xml I wrote in its .config directory... and really get a bit more verbose about errors
11:42ask6155: there doesn't seem to be info on controlling fan speed except for the info in the status matrix
11:45RSpliet: ask6155: for anything newer than 1st gen maxwell, I don't think nouveau controls the fan at all. It's part of the proprietary PMS firmware we have no choice but to load.
11:46ask6155: my card is the gt 730, is that newer?
11:52ask6155: I cannot find my card on the codename page
11:54ask6155: my renderer string is given as NV106 but that block has only gt 720
12:09RSpliet: That's older
12:51cangqiong: hi, can nouveau run opencl now?
15:31emersion: skeggsb: hi! i've submitted a nouveau patch a while ago, any news about it?
16:32TheLemonMan: karolherbst, I have a dmesg log for a problem similar to #86
16:32TheLemonMan: no wonders, we both have the same laptop model
16:33karolherbst: TheLemonMan: mind attaching it to the bug if you can?
18:48RSpliet: Hello X.org/xf86-drv-nouveau my old friend! :-D imirkin would be proud
18:50imirkin: should work fine.
18:51RSpliet: Works like a charm. Apparently it's hard to teach gdm/wayland the trick of not setting the monitors native resolution, whereas an Xorg.conf is kind of foolproof
18:51imirkin: RSpliet: what's the problem?
18:51ccr: "I've come to use you again .. because Glamor is softly creeping .. let it draw while I was sleeping .."
18:52RSpliet: imirkin: the problem is that I have a GT640. My 4K monitor isn't impressed with it's outputting capabilities
18:52imirkin: ccr: well done ;)
18:52imirkin: RSpliet: i mean ... it should work
18:52imirkin: which GT 640 is this? GK107?
18:52RSpliet: Not on HDMI for sure
18:52RSpliet: yep
18:52imirkin: you should totally be able to get 4k@30
18:52RSpliet: with YUV4:2:0...
18:52imirkin: no, with RGB
18:53imirkin: 4k@60 with YUV 4:2:0 (which nouveau doesn't support)
18:53imirkin: RSpliet: do you have the EDID handy?
18:53imirkin: (e.g. xrandr --verbose)
18:53RSpliet: https://paste.centos.org/view/4386f98a
18:54RSpliet: So... you're right that it should work. Sort of. I think HDMI can do 297MHz?
18:54imirkin: HDMI can do 340. but we have it limited to 297
18:55RSpliet: So does NVIDIA, according to page 12 of https://www.pny.com/file%20library/company/support/product%20brochures/nvidia%20quadro/english/quadro-and-nvs-display-resolution-support.pdf
18:56imirkin: not actually sure that they do
18:56imirkin: there's just no common resolutions above 297 but below 340
18:56RSpliet: Anyway, yes, I was slightly suspicious that plymouth and my VTs seem to work at 4K
18:57RSpliet: Didn't put 2 and 2 together
18:57imirkin: now if weston or whatever is insisting on the 4k@60 mode, ideally nouveau drm should be rejecting it
18:57imirkin: but even if it's not, it ain't gonna happen ... you need scrambling and divided tmds clock
18:58RSpliet: Yeah... Not sure what's going on now tbh. I get a big grey square in the centre of my monitor, and the monitor says it's driving 2992x2160
18:58imirkin: huh
18:58imirkin: sounds like something weird is going on
18:58RSpliet: Which is an interesting way for the GPU to fail
18:58imirkin: Xorg should be able to do 4k@30 no problem though
18:59imirkin: perhaps they assume that we can do yuv4:2:0 and then we can't?
18:59imirkin: but the modeline actually doesn't take all that stuff into account
18:59imirkin: it's meant for rgb (or yuv444) values, and then any funny bpc business is adjusted behind-the-scenes
18:59RSpliet: The monitor does give a special YUV420 line in the EDID
19:00imirkin: right, it has special VIC's for that
19:00RSpliet: I might hack around X.org conf to do 4K@30Hz and call it a day, unless you want me to investigate something further
19:00imirkin: i think for things to work, we'd have to set those VIC's as well
19:00imirkin: well
19:00imirkin: you should be able to have no funny overrides in xorg.conf
19:00imirkin: and things should Just Work (tm)
19:00RSpliet: even with the modeset driver?
19:01imirkin: ya
19:01RSpliet: I mean ideally yes
19:01imirkin: except then you'd be using glamor
19:01imirkin: which you probably don't want
19:01RSpliet: I don't know what I want anymore. It's been too long since I've done a deep dive
19:01RSpliet: I'm getting corruptions now though
19:02RSpliet: Not sure if just firefox, but parts of the webpage were rendered in the wrong location (e.g. as if you cut out a big block of image and just pasted it up 200px higher)
19:03imirkin: yeah, i've heard that webrender triggers issues
19:03imirkin: try disabling it
19:03imirkin: or the GPU assist or whatever
19:04RSpliet: I also now seem to have to clock my GPU to the max to get decent perf
19:04RSpliet: Nice
19:05imirkin: it's a lot of pixels
19:05imirkin: i counted.
19:05imirkin: took a while.
19:05RSpliet: Yeah, it's defo quite a bit more than my previous 1280*1024-7
19:06RSpliet: Or... I think it had about 7 dead pixels
19:06imirkin: it still tried to render the dead pixels though
19:06imirkin: a stencil mask wasn't applied to each render ;)
19:06RSpliet: Could be... they're heisenpixels to me
19:07RSpliet: Weird how full-screen applications suddenly don't make sense anymore
19:18RSpliet: imirkin: I removed everything except the device section (that specifies I want nouveau, not modeset), and things still work fine. Removing the device section makes X fail -> modeset bug/issue/...
19:18imirkin: right
19:18imirkin: not sure why modeset wouldn't work *at all*
19:18imirkin: its mode selection should be largely identical
19:23RSpliet: imirkin: https://paste.centos.org/view/4b26c9ac
19:24RSpliet: Doesn't really show anything out of the ordinary
19:24imirkin: what's the problem with modeset?
19:25RSpliet: black screen, nothing happens
19:25imirkin: seems suboptimal indeed
19:25RSpliet: I have very few use-cases for an all-black screen
19:25imirkin: yea, dunno offhand
19:25imirkin: (as to what would be going wrong)
19:34RSpliet: Actually, this is at least a bit interesting
19:34RSpliet: Here's a nouveau log : https://paste.centos.org/view/a581c9e0
19:35RSpliet: Note how modeset has four lines saying "Not using default mode", 3 of which are 4K
19:35RSpliet: Nouveau doesn't say that
19:35imirkin: i think nouveau just keeps quiet about that
19:35imirkin: note that there still noe @594mhz modes in the list
19:36RSpliet: Modeset does keep them in its list
19:36imirkin: apr 14 20:20:31 Tuvok /usr/libexec/gdm-x-session[13707]: -2
19:36imirkin: tsk tsk tsk
19:36imirkin: update to xf86-video-nouveau 1.0.17 :)
19:37imirkin: you're on 1.0.15 it looks like?
19:37imirkin: lots of little bits fixed, dunno if any will be relevant to you though
19:37imirkin: at least some are, if you force-enable DRI3
19:37RSpliet: https://koji.fedoraproject.org/koji/packageinfo?packageID=5871
19:37RSpliet: Looks like it indeed
19:38RSpliet: be nice if someone cared about that package...
19:39RSpliet: Looks like the last serious upgrade of it was in 2017... by skeggsb :-P
19:40imirkin: ah yeah, he stopped caring about xf86-video-nouveau around that time
19:42RSpliet: Doesn't look like there's very many relevant changes tbh
19:43imirkin: the big one is DP-MST dynamic connector stuff
19:44imirkin: also some depth=30 fixes
19:44imirkin: also some present/dri3 fixes
19:44imirkin: and made that "-2" error is now a lot more verbose
19:49RSpliet: I don't suppose you know how to get Xorg-like logs from a wayland session?
19:49imirkin: wayland? definitely not. it'd be from the compositor - look at the compositor's help
19:49RSpliet: who is the compositor for gdm...?
19:49imirkin: if i look in backlog, i should be able to figure it out for sway
19:50imirkin: search me.
19:50imirkin: (and you won't find the answer...)
19:52RSpliet: it was a long shot
19:52pmoreau: Which alignment is used when allocating buffers in global memory? I don’t think it depends on the underlying type, right?
19:52imirkin: pmoreau: "underlying type"?
19:53imirkin: if it's a "buffer" type, we will do sub-allocation
19:53imirkin: and there the alignment is based on whatever you ask for
19:53imirkin: if it's a texture, it'll always have page alignment
19:54imirkin: (large page alignment if it's big enough)
19:54pmoreau: Let’s say I want to allocate a buffer containing float4, is the address to the first element aligned to sizeof(float4) or to fixed larger value?
19:57pmoreau: > and there the alignment is based on whatever you ask for
19:57pmoreau: But AFAICT APIs only let you specify how big you want your buffer, but there is no way to specify its alignment is there?
19:58imirkin: pmoreau: which API?
19:58pmoreau: OpenGL and OpenCL at least
19:58imirkin: i'm talking about nouveau's internal buffer allocation APIs
19:59pmoreau: Ah, okay
20:00pmoreau: I’m trying to figure out if I do a `glBufferData(GL_ARRAY_BUFFER, sizeof(float4) * 10, nullptr, GL_STATIC_READ);` for example, how will the address to the first element be aligned.
20:00RSpliet: imirkin: oh btw, things work fine on Wayland from my laptop, which is i915 and also doesn't support 4K@60Hz.
20:01imirkin: pmoreau: check how nouveau allocates a buffer of such a size
20:01imirkin: i don't remember offhand
20:01imirkin: nv50_resource.c maybe?
20:01RSpliet: which means I may have to have a session with Lyude to debug this :-D
20:01imirkin: or nouveau_buffer.c
20:01pmoreau: Thanks, will check there
20:04Lyude: hello
20:04Lyude: GT216, that will be fun
20:05imirkin: GK107 according to RSpliet
20:05Lyude: oh yay that's better :)
20:05imirkin: apr 14 20:17:12 Tuvok /usr/libexec/gdm-x-session[13707]: (--) NOUVEAU(0): Chipset: "NVIDIA NVE7"
20:05imirkin: the logs seem to support that claim
20:05RSpliet: I can support that claim too also
20:05pmoreau: At least the "G" part was correct ;-)
20:06Lyude: any eye witnesses? ;P
20:06RSpliet: aye!
20:07ccr: "there are FOUR lights!"
20:08RSpliet: Lyude: TL;DR: X.org and xf86-drv-nouveau works with my brand-spanking new 4K monitor, both X.org + modeset, and wayland don't work.
20:10RSpliet: Oh, and i915 (ehh... i5-6200u... that's... ehh... Skylake, HD graphics 520, also doesn't do 4K@60Hz) plus wayland works fine too, albeit as a secondary monitor
20:10pmoreau: Okay, so `nouveau_buffer_allocate()` calls `nouveau_mm_allocate()` with no alignment, and the latter calls `nouveau_bo_new()` with an alignment of 0.
20:12Lyude: RSpliet:!! that's surprising
20:12imirkin: pmoreau: well, the underlying buffer will always be aligned to 4 or 128k
20:13imirkin: pmoreau: but nouveau_mm_allocate will actually perform sub-allocation as well
20:13imirkin: so you have to check how *it* aligns
20:15pmoreau: Ah right, with that `<< slab->order`
20:15Lyude: RSpliet: are the modes it's setting for wayland vs. the modes it's setting for modeset any differewnt?
20:16RSpliet: Lyude: I don't know how to extract any meaningful data out of the gnome-shell wayland session
20:16RSpliet: also, have you encountered this gem? https://gitlab.gnome.org/GNOME/mutter/-/issues/1232
20:16Lyude: RSpliet: /sys/kernel/debug/dri/0/state (replace 0 for 1 if that's where your nv gpu lives)
20:17Lyude: RSpliet: nope, MrCooper seems to have though
20:18RSpliet: Lyude: https://gitlab.gnome.org/jadahl/mutter/-/commit/4c7a846dc89098149cab0da6c1ac7573eb8e465c
20:18RSpliet: They... may have fixed this issue literally today
20:18Lyude: oooh lol
20:19pmoreau: Which is at least 7, or the first power of two containing the whole buffer. Interesting.
20:20pmoreau: Okay, probably not the approach I want to use for managing local memory.
20:33RSpliet: Lyude: i was wondering though, 'd you reckon you could update the Fedora (33, 34) package for xorg-x11-drv-nouveau ?
20:34RSpliet: I don't think I'll be using it for long, but it's a bit odd that it's 4 years out of date :-D
20:36RSpliet: (Xorg already crashed twice in an hours time, with xf86-drv-nouveau. Wayland was a lot more stable for me... so as soon as my custom-built mutter with back-ported fix, courtesy of one of the gnome-shell people, comes through I might bounce back)
20:38Lyude: RSpliet: maybe, I can't remember if I have access to the packages for that or not. we generally expect people to use modesetting though
20:38Lyude: (which is why it hasn't been updated)
20:47pmoreau: Grrrr, this is going to be a pain to support with the kernel args living in shared…
20:49imirkin: Lyude: yeah, but modesetting (a) doesn't work and (b) definitely doesn't work pre-nv50
20:49imirkin: Lyude: i would definitely advise people to use -nouveau always at this point
20:49imirkin: there was a short period of time when it didn't support DP-MST, but it does now (and has for a very long time)
20:49Lyude: imirkin: doesn't work in general or doesn't work on this issue?
20:50imirkin: Lyude: i mean, in general, it's just unstable and a bad experience
20:50imirkin: Lyude: in this particular instance, something weird is happening, but i wouldn't get hung up on that
20:50imirkin: Lyude: it relies on mesa (as you probably know), and that's not good for a long-running application like Xorg
20:56RSpliet: Lyude: as for my particular issue: the mutter fix fixed it indeed
20:58Lyude: i'm, not sure how much I really agree with that - quite a number of wayland compositors already rely on mesa, and I cannot even remember the last time someone pointed me at glamor issue modesetting was hitting on nouveau. like-I'm sure these issues exist, but I haven't seen anywhere near enough of them to justify actually switching back to a very lightly maintained driver instead of just trying to
20:58Lyude: actually fix the modesetting issues so we're not stuck maintaining driver DDXs forever
21:01RSpliet: it still struggles with 1920x1080@24Hz video stretched to most of my screen - same video plays fine in small. Even at full clocks. frames dropping harder than the beat
21:02RSpliet: Youtube decided to scale back to 480p, but still slow!
21:02Lyude: huh
21:02imirkin: Lyude: yeah, skeggsb agrees with you
21:02Lyude: RSpliet: did this perform better on modesetting/nouveau's ddx?
21:02imirkin: Lyude: which is why i get to tell everyone coming in here with issues to just use -nouveau
21:02imirkin: and then all their problems are magically solved
21:02imirkin: :(
21:03RSpliet: Lyude: it performed better when I had a 1280x1024 monitor
21:03RSpliet: X.org was worse
21:03RSpliet: (was dropping frames even when keeping the video small)
21:03Lyude: and then the issues w/r/t modesetting + nouveau don't get fixed :P
21:03imirkin: Lyude: they don't get fixed either way.
21:03RSpliet: Lyude: I think it's fair to say that modesetting/glamor won't get fixed for pre-NV50
21:04Lyude: RSpliet: i don't think we default to it for pre-nv50 either
21:04imirkin: the biggest issue in mesa is lack of error handling
21:04Lyude: for that reason :P
21:04imirkin: that's been an issue since day 1
21:04imirkin: never has anyone tried addressing it
21:04RSpliet: Lyude: what does it default to then?
21:04imirkin: Lyude: yeah, but you don't udpate -nouveau either
21:04Lyude: RSpliet: nvidia ddx iir
21:04RSpliet: Lyude: nouveau ddx? In which case, I'd encourage to keep it updated just a little bit :-D
21:04Lyude: imirkin: would you like to maintain the package? this is a genuine question
21:05Lyude: RSpliet: *nouveau ddx oops
21:05imirkin: Lyude: what does maintenance entail?
21:05imirkin: Lyude: and would maintenance allow removing the hackpatch which forces modesetting on everyone?
21:06imirkin: bumping a package version every couple years doesn't seem like _such_ a burden
21:06RSpliet: https://koji.fedoraproject.org/koji/packageinfo?packageID=5871
21:06RSpliet: It doesn't even rebuild for fx34
21:07RSpliet: ... because the Xorg ABI changed slightly I believe
21:07imirkin: RSpliet: there's a patch for that
21:07RSpliet: which means at this point it either *has* to be updated, or dropped.
21:07imirkin: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=e80e73ced69b15662103d0fd6837db4ce6c6eb5b
21:07RSpliet: and dropped means dropping pre-nv50 users
21:07imirkin: presumably this guy?
21:07RSpliet: imirkin: I know ;-)
21:07Lyude: imirkin: I meant for fedora-and you just update the package sometimes. maybe fix a build error on a blue moon. but no - i don't think we're really changing the decision to make it default
21:08imirkin: Lyude: ok, then i have no interest in fedora
21:08imirkin: since it doesn't seem to have usability in mind
21:09Lyude: yes. we try very hard to make fedora difficult to use
21:09imirkin: eh, it was pretty easy
21:09Lyude: RSpliet: i'll try to update the package this week then and poke me if I forget
21:09Lyude: we definitely don't want to drop this entirely
21:09RSpliet: Lyude: thanks!
21:10imirkin:&
21:10RSpliet: Sorry, didn't mean to volunteer you for the job in particular, there were also skeggsb, kherbst and airlied as candidates :-P
21:10RSpliet: But sounds like a sensible thing to chase up before f34 gets released
21:11Lyude: RSpliet: no it's ok lol, i'm glad someone raised this somewhere
21:11RSpliet: meanwhile I'm back on Wayland. Hooray for that just-in-time mutter fix
21:17pmoreau: This does not seem ideal…
21:17pmoreau: EMIT: st u8 # s[$a0+0x34] %r202 (8)
21:17pmoreau: EMIT: st u8 # s[$a0+0x35] %r202 (8)
21:18pmoreau: %r202 used to be an immediate, but somehow disappeared entirely
21:57RSpliet: karolherbst: building a kernel with a bumped usleep range in base507c.c, as I too am seeing quite significant CPU usage in nv50_disp_atomic_commit_work
22:29RSpliet: imirkin: do you reckon any of those (present) fixes for nouveau ddx improve stability from 1.15 to 1.17? Because... this gk107 is rock-solid on Wayland, but X.org got it on its knees within minutes. Lots of moving targets obvs, there's firefox with youtube video playback and things...
22:30RSpliet: oh, you suspended yourself... hope someone brings you back to the foreground at some point
22:35imirkin: RSpliet: that's definitely surprising
22:35imirkin: someone had 3x 4k rotated screens
22:35imirkin: and that worked fine.
22:35imirkin: (with a diff gpu admittedly)
22:38RSpliet: imirkin: well, I'm happy to provide you with info if you ever want some. Never appreciated how easy it still is to switch back and forth between X and wayland, so doesn't seem a huge effort.
22:41imirkin: RSpliet: well, you'd have to try to see what's going on
22:42RSpliet: Ya. Usually it's hard lock-ups where even magic sysrq is futile...
22:45RSpliet: wow, a new record in powertop
22:45RSpliet: 3.97 W 3961 ms/s 1,6 kWork nv50_disp_atomic_commit_work
22:46imirkin: ding ding ding ding!
22:46RSpliet: How many milliseconds are there in a second again?
22:46imirkin: you got mutliple cpu's don't ya
22:46RSpliet: cores ;-)
22:46imirkin: semantics
22:46imirkin: RSpliet: if you're force-enabling DRI3, then 1.0.17 definitely fixes some pretty unpleasant bugs
22:46RSpliet: To be precise, I have 6 cores
22:47RSpliet: So how do I get
22:47RSpliet: 17.4 W 17426 ms/s 2,0 kWork nv50_disp_atomic_commit_work
22:47RSpliet: ?
22:47imirkin: you got cores you didn't even know about
22:48RSpliet: That's what I tell the unimpressed peers at the gym...
22:49imirkin: reaching there...
23:01Lyude: RSpliet: btw-be careful measuring cpu usage if you have a lot of logging enabled,
23:01Lyude: also - powertop isn't great at measuring power
23:02Lyude: well on laptops anyway
23:02Lyude: *desktops
23:02imirkin: also be careful running tcpdump inside an ssh session :)
23:02Lyude: sorry-laptops is where it kind of works
23:07RSpliet: Lyude: oh this isn't about serious profiling or anything
23:07Lyude: ah ok
23:11RSpliet: karolherbst: your proposed change in base507c.c:154 (usleep(1,2) -> usleep(10,200)) doesn't remove nv50_disp_atomic_commit_work from the list in powertop. Still seeing 300-400ms/s (the excesses above were while rolling a kernel, this may have skewed measurements a bit :-P)
23:12RSpliet: Proper profiling will have to wait for another time.... it's catching-z's time now
23:18karolherbst: RSpliet: ohh, you see the same issue?
23:18RSpliet: yep
23:18karolherbst: ahh
23:18karolherbst: since forever?
23:18RSpliet: Dno
23:18karolherbst: okay...
23:18karolherbst: maybe I check on my nv50 then....
23:18RSpliet: I only noticed performance problems today... as performance tends to matter when I switched from 1280x1024@60Hz to 3680x2160@30Hz :-P
23:19RSpliet: Or w/e 4K is
23:19karolherbst: :D
23:19karolherbst: who knew
23:19karolherbst: but...
23:19karolherbst: it might also just be 30 hz
23:19karolherbst: because 30hz.. sucks
23:19karolherbst: no idea why they even bothered with anything below 60hz
23:19RSpliet: Well, yeah, but... I don't really have a choice
23:19karolherbst: 2560@60?
23:20RSpliet: Oh actually I tried that, but the blur is worse than the low refresh rate
23:20karolherbst: uhh
23:20karolherbst: annoying
23:20karolherbst: just use DP :p
23:20karolherbst: oh wait, it's not intel :p
23:20RSpliet: Yeah, that would involve buying a new graphics card
23:21RSpliet: Heard they're hard to come by these days
23:21karolherbst: I guess you habe DVI and HDMI?
23:21karolherbst: *have
23:21RSpliet: Yep, and VGA
23:21RSpliet: monitor just has HDMI and DP
23:21RSpliet: Oh btw, this is on GK107, with and without reclocking
23:22karolherbst: huh?
23:22karolherbst: kepler can do HDMI 2...
23:22RSpliet: Kepler has a pixel clock which is limited to 297MHz
23:22karolherbst: ohh wait
23:22karolherbst: no
23:22RSpliet: on HDMI
23:22karolherbst: crap...
23:22karolherbst: but it can do DP 1.2...
23:22karolherbst: ufff
23:22RSpliet: Yeah... if Asus had only soldered that port on my PCB :-D
23:22karolherbst: ....
23:22karolherbst: how stupid
23:23RSpliet: Anyway, youtube 1920x1080@24Hz video is choppy at (near-)full screen. Looks alright in a small youtube window
23:23karolherbst: yeah.. I guess perf is terible anyway
23:23RSpliet: so there's other perf issues. Was hoping they'd be related, but eh
23:23karolherbst: yeah.. if the CPU is going crazy, maybe that's our problem
23:24karolherbst: but you see that on kepler, right?
23:24RSpliet: Yep
23:24karolherbst: okay.. shit
23:24RSpliet: AC: core 901 MHz memory 1782 MHz
23:25karolherbst: I habe a gk106 here actually... might just try it with that
23:25RSpliet: It's a DDR3 card, so not exactly well-endowed when it comes to memory bandwidth
23:25karolherbst: I have a gtx 660 here :D
23:25RSpliet: But... an i915 Skylake (HD 520, from like... 2015?) performs better :-P
23:25RSpliet: Yeah, this is GT 640
23:26karolherbst: actually... I don't really need this 660 and it's mine as well
23:26karolherbst: I have plenty of other keplers
23:26RSpliet: I should have VDPAU stuff working, but... I don't think that matters for youtube anymore because everything's Opus or h265 these days
23:26karolherbst: hard to tell
23:26karolherbst: but probably
23:26RSpliet: Oh, and the CPU is an AMD FX6300. So again not impressive, but defo better than my laptop
23:27RSpliet: Mainly wondering why upscaling video is so expensive
23:27karolherbst: not being able to do 4K@60 would really annoy me though :D
23:27karolherbst: it's already annoying me enough that you have to suffer with that :D
23:28karolherbst: RSpliet: because 4k is just expensive
23:28RSpliet: Yeah, it will annoy me soon enough. I suspect AMD RX 6500 will come to the rescue eventually, but until then it's alright
23:28karolherbst: but essentially.. anything 4k related and nouveau just sucks...
23:28karolherbst: I just don't have the time to deal with that
23:28RSpliet: karolherbst: clocking my memory up hardly makes a difference. I think nouveau is doing sth wrong and it's bottlenecked on a component it shouldn't bottleneck on :-)
23:28RSpliet: Yeah fair
23:29karolherbst: RSpliet: I'd assume the video is scaled up in software
23:29karolherbst: what ddx are you using or wayland?
23:29RSpliet: Wayland
23:29karolherbst: k
23:29RSpliet: nouveau ddx was worse w/ video playback
23:29RSpliet: well
23:29RSpliet: youtube playback
23:30karolherbst: of course it is :p
23:30RSpliet: doesn't nouveau DDX have libXv for slightly more efficient buffers and overlays?
23:30karolherbst: doesn't help you if software doesn't care about libxv
23:31RSpliet: yeah... back in the old days Flash player did - after lots of nagging w/ Adobe and only in an experimental form.
23:31karolherbst: terrible APIs are disliked by everybody
23:31RSpliet: Flash, or libXv?
23:32karolherbst: both
23:32RSpliet: both!
23:32RSpliet:nods
23:32karolherbst: not that vdpau/vaapi are that much better, but you target vdpau anyway, because nvidia
23:32RSpliet: not sure if Firefox tries tbh
23:32karolherbst: and then you stop caring, because these days everybody is doing vdpau
23:32karolherbst: they might target libva
23:32karolherbst: and then you have bridges between va and vdpau
23:32karolherbst: so....
23:41RSpliet: ah, Firefox doesn't enable vaapi by default.
23:42RSpliet: forced on webrender and vaapi, and all is good now!
23:42RSpliet: living on the edge :-D
23:44RSpliet: also force-enabled webrender. I suspect the software fallback is just for (int x = 0, y = 0; ...) { putpixel(x,y,colour) }
23:51RSpliet: Full screeen 4K@24fps YT content without dropping frames... as long as it doesn't have to draw a UI overlay. Colour me impressed!
23:52karolherbst: oh wow :p
23:52karolherbst: who knew, sw scaling is terrible
23:53RSpliet: Such surprise
23:54RSpliet: But yes, just a shame that Firefox' defaults are apparently really bad
23:54RSpliet: they probably have their reasons, nouveau stability isn't a given, but still
23:55RSpliet: I went from utter despair this morning to "oh I don't have to replace my GPU just yet" over the course of... 15 hrs :-P
23:55imirkin: RSpliet: xorg is all good now?
23:55imirkin: nouveau does support xv, but i dunno that it's materially faster than the application doing it by hand
23:55imirkin: kepler doesn't have anything too useful to do with it
23:57RSpliet: imirkin: wayland, soz
23:58RSpliet: Xorg was unstable when I tried it earlier in the eve, but with that mutter fix, Wayland (and presumably xorg+modeset) are working too now