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