00:56qeeg: hey, is there anything known about reclocking for pascal yet? i have a gtx 1080 that i wanna help with nouveau on but i dunno if reclocking is supported :p
00:56imirkin: no reclock on pascal.
02:21tertl3: hi imirkin
02:22tertl3: dose nouvea have a "Video Decode Acceleration Framework" like the one metioned on the wikipedia page that apple made
02:22tertl3: i was looking at the wikipedia for vdpau
02:26imirkin: nouveau supports vdpau (and va-api), via shared state trackers i nmesa
02:31tertl3: do yo uhave any idea how I can get permissino to do this
02:31imirkin: to do what?
02:31tertl3: cat /dev/urandom > /dev/fb0
02:31imirkin: not offhand
02:32imirkin: only `cat` gets the sudo
02:32imirkin: you still open the file as yourself
02:34HdkR: sudo sh -c "cat /dev/urandom > /dev/fb0"
02:41tertl3: nice thank you
02:41tertl3: i want to do some demo scene video card hack
02:41tertl3: and make it flash a bunch of colors or somnething
02:42tertl3: i guess theres not repl for gui programs?
02:42tertl3: oh wait
02:42tertl3: never mind
03:03Frosku: Hi, I'm trying to use an external monitor in a laptop with intel + discrete nvidia graphics. It shows some text during bootup (mirror of main display) but then doesn't appear once X is loaded (xrandr shows one monitor connected). Any ideas?
03:04Frosku: lspci | grep VGA output:
03:04imirkin: Frosku: pastebin xorg log
03:05imirkin: and dmesg too, while you're at it
03:11Frosku: https://pastebin.com/g6eVE2ZE - dmesg
03:12HdkR: `NVIDIA TU117` uh oh :)
03:12Frosku: I may need to restart X for Xorg.log, looks like I accidentally overwrote it trying to do X -configure
03:12Frosku: Is that bad?
03:12imirkin: HdkR: could be fine
03:12Frosku: brb restarting X
03:13imirkin: [ 266.263695] nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for HDMI-A-2
03:13imirkin: that's probably not great
03:17Frosku: https://pastebin.com/s1sLtDKt - Xorg.log (actually gdm/greeter.log -- this system doesn't seem to save Xorg.log, but it's got the same info in)
03:20imirkin: Frosku: 4K monitor plugged in?
03:20Frosku: 4K builtin display too
03:20imirkin: everything seems fine
03:20imirkin: can you pastebin the output of 'xrandr'
03:21imirkin: xrandr --setprovideroutputsource 1 0
03:22imirkin: this should make the additional outputs appear
03:22Frosku: Aaaand it's doing something
03:23Frosku: Well the TV went black now instead of showing 'no input'
03:23Frosku: New xrandr output
03:24Frosku: I'm not sure what DP-1-3 is
03:24Frosku: I don't have 2 external screens connected
03:25imirkin: whatever it is, it's disconnected
03:25Frosku: OK so I turned TV off then on, now it seems to work...
03:25imirkin: hm, i wonder why the 60hz mode isn't visible
03:25Frosku: At a guess, shitty non-HDMI2 cable
03:26imirkin: i didn't think cables could be hdmi1 or hdmi2
03:26imirkin: the high tmds rates use a clock divider + magic
03:26Frosku: I'd imagine the port is HDMI2 just by virtue of this being a 2020 laptop
03:26imirkin: (aka scrambling, but i'm not sure how that helps)
03:26imirkin: anyways, can you try setting a lower resolution?
03:27imirkin: e.g. xrandr --output HDMI-1-2 --mode 1920x1080
03:27Frosku: Sure, its working in 30Hz though, just not sure why 60 doesn't show
03:27Frosku: I turned the TV off then on again
03:27imirkin: can you run
03:27imirkin: xrandr --verbose
03:27Frosku: And it decided to work
03:27imirkin: it could be that it started in HDMI2 mode
03:27imirkin: and then decided that wasn't working and fell back to HDMI1
03:28imirkin: HDMI2 stuff isn't *the* most tested stuff in the world
03:28imirkin: usually our testing is "oh look, this tv works with this board. must be good."
03:28imirkin: we don't exactly have huge labs of test equipment =/
03:29HdkR: Even if you had labs full of the stuff, you need CI testing it constantly which is even less likely :)
03:29Frosku: tbh I wouldnt be *massively* shocked if this GPU just cant handle 2x 4K@60 monitors
03:29imirkin: and enabling the higher frequencies is a slightly finicky process
03:29imirkin: Frosku: that's not the issue
03:29imirkin: the issue is like we write scdc first, and then do something
03:29Frosku: Verbose output
03:29imirkin: or we do something first, and then write scdc
03:29imirkin: it's not like we have docs on how it should be done
03:30Frosku: Y'all are doing Gods work, no thanks to nvidia
03:30imirkin: ok, well --
03:30imirkin: according to that EDID there are no 60hz modes
03:30imirkin: some TV's only allow some ports to be hdmi2.0
03:31Frosku: Maybe I need to get an EDID file or something? I remember having to do that for a monitor before
03:31imirkin: *very* unlikely
03:31imirkin: or maybe it only supports 4k@60 with 4:2:0? that'd be sad
03:31Frosku: Though that was a super early gen 4K@60
03:31imirkin: YCbCr 4:2:0 Video Data Block:
03:31imirkin: VIC 96: 3840x2160 50.000 Hz 16:9 56.250 kHz 297.000 MHz
03:31imirkin: VIC 97: 3840x2160 60.000 Hz 16:9 67.500 kHz 297.000 MHz
03:31imirkin: but we don't support 4:2:0 modes
03:31Frosku: This... is not
03:31Frosku: Whats 4:2:0?
03:32Frosku: Sorry, I know very little about GPU/video stuff
03:32imirkin: ever heard of RGB?
03:32imirkin: so that's like "full data"
03:32HdkR: HDMI 2.0 can't support 4k60 without 420
03:32imirkin: HdkR: you're mistaken.
03:32HdkR: (or DSC)
03:32imirkin: HdkR: 4k@60 4:4:4 is 594mhz
03:33imirkin: Frosku: basically you get 8 bits of red, 8 bits of green, etc
03:33imirkin: times the number of pixels
03:33HdkR: Oh yes, I was thinking of the HDR modes. :)
03:33imirkin: (+ some extras, i won't go into that)
03:33imirkin: there is also a different "basis" for describing color, "YUV"
03:33imirkin: which has different primaries than red/green/blue, but is otherwise identical
03:33imirkin: this is known as YUV 4:4:4
03:34imirkin: but with the way that the YUV primaries are chosen, you can actually get away with having a decent-looking image if you have the "full" data for the "Y" color, and 1/4th the data (i.e. one value for a 2x2 group of pixels) for the "UV" data
03:34imirkin: so it's a way of transmitting a full-color image but with a bit less precision
03:35imirkin: which requires fewer bits and thus lower clocks
03:35Frosku: Thats 4:2:0?
03:35Frosku: And it isnt supported?
03:35imirkin: (there's also 4:2:2, which is the same idea, but one value for 2x1 group of pixels)
03:35imirkin: the hardware supports it
03:35imirkin: the TV supports it
03:35imirkin: nouveau doesn't support it.
03:36imirkin: Frosku: i'd double-check whether this is plugged into the "main" port of the TV, could be that only some ports are HDMI2-capable
03:36Frosku: It's... HDMI-2 port I think
03:36Frosku: So I can try HDMI-1
03:37imirkin: the edid doesn't say which samsung tv this is
03:37imirkin: it definitely seems like a newer one
03:37imirkin: has edid blocks i've never seen before :)
03:37Frosku: It's... idk the model, 2018ish curved 65" I think
03:37imirkin: Vendor-Specific Video Data Block (HDR10+), OUI 90-84-8B:
03:37imirkin: Application Version: 1
03:38Frosku: Still 30Hz on HDMI 1 port
03:39imirkin: i can't imagine that a 2018 tv wouldn't support hdmi2
03:40Frosku: I'll get the model number in a bit
03:40imirkin: i think i found it
03:40imirkin: but it's inconclusive
03:41Frosku: Either way, for now it's not an issue as I'm not planning to use it for more than a code review screen and/or crappy YT videos that are probably 24fps anyway :)
03:41Frosku: So thank you!
03:41imirkin: you're welcome
03:42Frosku: How can I persist those changes btw? .xprofile or something?
03:42imirkin: some DE's will do it automatically
03:42Frosku: I'm on i3
03:42imirkin: you should get i3 to run it on startup
03:43imirkin: i dunno how you do that, but i sorta assume that's a thin
03:43Frosku: I usually put that kinda thing in .xprofile
03:43imirkin: btw, you may want to reduce the resolution if all you're going to do is play youtube videos
03:43imirkin: i don't think you gain anything from 4k, and it's a LOT of pixels to shuffle around for no reason over the pci bus
03:44Frosku: I likely will, it seems quite stable right now but I have no load on the bus
03:44imirkin: the image is rendered on your igpu
03:44imirkin: and then shipped to the dgpu
03:44Frosku: Is nouveau ever likely to support 4:2:0 btw?
03:47imirkin: moderately likely.
03:47imirkin: it should be easy
03:47imirkin: just need to know what thing to poke in what place
03:47imirkin: and i actually have all the hardware here
03:47imirkin: just need to find the time when i can reboot my box a lot
03:47imirkin: and get the blob set up again
03:48imirkin: (my main desktop doubles as the dev box, so ... yeah)
03:48Frosku: Out of interest, why am I rendering on iGPU and shipping to dGPU? Isn't the dGPU significantly better?
03:52imirkin: it's just the way things get set up
03:52imirkin: you can render on dgpu as well
03:53imirkin: Xorg will pick one gpu to render on
03:53imirkin: so ultimately the final scanout image (except for some full-screen cases) will be put together by Xorg
03:53imirkin: also with nouveau, the dGPU is not better
03:53imirkin: because it comes up with boot clocks which we can't change
03:54imirkin: so you get like ... 5% of the perf theoretically available
03:54Frosku: Remind me to buy an AMD laptop next time
03:54imirkin: yeah, definitely
03:54imirkin: stay away from nvidia.
05:19ccr: but hey, nvidia is going to make CPUs too now .. I wonder how open or closed those will be :D
05:20HdkR: (Nvidia already makes CPUs is the joke)
05:21HdkR: If Nvidia's purchase of ARM goes through then you could say they make a lot of CPUs
05:23imirkin: does ARM make CPUs?
05:24imirkin: i thought they just made IP's
05:24HdkR: Depends on your definition of make. They make CPU designs
05:24HdkR: But they don't physically go in to the sandbox and make them from the sand :)
05:24imirkin: but they don't make the .... i forget the naem ... transistor layout thing
05:25imirkin: some abbreviation
05:25HdkR: The verilog sure
05:25HdkR: VLSI, HDL, etc
05:25ccr: as far as I've understood, they make the CPU block design and then licensees can add other blocks to it for SoC
05:26imirkin: VHDL / Verilog
05:26imirkin: but there's the transistor arrangement i thought too
05:26imirkin: maybe not
05:26ccr: isn't that synthesized from VHDL/Verilog?
05:26imirkin: maybe it is floorplanning
05:26imirkin: ccr: there are practical concerns that require manual intervention
05:26ccr: of course
05:26imirkin: a lot of stuff is laid out automatically though
05:27imirkin: from netlists or whatever, which can be described in those languages
05:29HdkR: Exact details at that level are of course between the Licensee and Licenser. Can't really tell from the outside :)
06:09pmoreau: imirkin: Re “"nv50: add compute support" -- did you mean "nv50/ir: offset accesses to shared memory"?” I meant the latter, indeed. Not quite sure how that happened 🤦
11:14ask6155: Is manual reclocking dangerous?
11:39karolherbst: not really
11:45ask6155: I can see a lot of kworkers eating my cpu, why is that?
11:45karolherbst: no idea
11:46karolherbst: maybe profile your kernel and see what's up
11:46ask6155: how do I do that?
11:46karolherbst: uhm... somehow with perf.. but I always forget the details and have to look it up myself
11:48ask6155: please tell me
11:49ccr: https://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu might help
11:50ask6155: It only happens with nouveau btw
11:50karolherbst: ccr: it doens't really :p
11:50karolherbst: ask6155: yeah.. it might be that we have some stupid loop somewhere
11:50ccr: ok :P
11:51ccr: there's an answer about perf usage there tho
11:51karolherbst: I think "sudo perf record -g -a sleep 100" or more seconds might help
11:52karolherbst: but you might have to install debug sysmbols or so
11:52karolherbst: but perf is always a tool you have to toy around a little until you get valueable data out of it or so
11:53ask6155: I got the report as it said/
11:53ask6155: But I don't know how to use the data
11:53karolherbst: "perf report"?
11:53ask6155: I meant I see perf report
11:53ask6155: what to do now?
11:54karolherbst: ehh... good question.. the UI is ...
11:54karolherbst: ohh wait
11:54karolherbst: there are nice GUI tools.. wait
11:54ask6155: aah I can see somethings
11:54karolherbst: ask6155: hotspot
11:54ask6155: kernel.vmlinux uses 44%
11:55ask6155: the command was kworker/u8:3+ev
11:56karolherbst: ask6155: https://i.imgur.com/jkYYAIX.png this is how hotspot looks like
11:57karolherbst: might be a bit easier to use
11:57karolherbst: ask6155: the question is rather in what functions it spends the most time
11:57karolherbst: and you might have to install debugsymbol packages for the kernel
11:58ask6155: https://imgur.com/xYuBViC perf screenshot
11:59karolherbst: ntfy wait
11:59karolherbst: busy loop?
12:00karolherbst: ahh yeah...
12:00karolherbst: skeggsb: base507c_ntfy_wait_begun is causing huge CPU waste for a user
12:01ask6155: is the kernel.vmlinux shared object also caused by it or is that a different issue?
12:01karolherbst: it's the same thing..
12:01karolherbst: the .. UI is a bit confusing
12:01karolherbst: some elements are included in other ones
12:01karolherbst: what's relevant is the "self" part
12:02karolherbst: that means the function itself consumes that much cycles
12:02karolherbst: the "children" number means: the function including all called functions
12:02karolherbst: if you open one of the entries, you should see some list or so...
12:02karolherbst: but again.. the UI is a bit weird to use
12:03karolherbst: but we have a busy loop inside base507c_ntfy_wait_begun
12:03karolherbst: which uses "ioread" to read state from the gPU
12:03karolherbst: so it all fits more or less
12:04karolherbst: we do have a "usleep_range(1, 2);" in tehre
12:04karolherbst: but I guess it's not enough :D
12:05ask6155: I like your funny words magic man
12:05karolherbst: if you are up for compiling you own kernel you could change base507c_ntfy_wait_begun
12:05karolherbst: and make the usleep_range a "usleep_range(10, 200)" or something like that
12:05ask6155: I'm not upto that ;(
12:05karolherbst: the parameters are min/max sleep times
12:06karolherbst: ahh, okay
12:07ask6155: so is the bug in the kernel or in a module?
12:07ask6155: is it fixable?
12:08karolherbst: it is fixable
12:10ask6155: So I suppose the bug is in the module which is in the kernel. So you'll make a commit and it'll be in the next release?
12:11karolherbst: hopefully? dunno how quick it will be. I am not that familiar with the code and skeggsb might have better insights on what needs to happen
12:13ask6155: I had made a git report a little time ago. But that also included other info about another bug? maybe you can also look into that?
12:13karolherbst: I think I saw it
12:14karolherbst: let's see...
12:15karolherbst: ask6155: ehh wait.. did you only write to the mailing list or also made a bug report somewhere?
12:15karolherbst: just seeing your email from 4 days ago
12:15ask6155: I wrote to the mailing list. I didn't get any reply so I made an issue on gitlab
12:15karolherbst: didn't see it there
12:16karolherbst: ohh, mesa
12:17karolherbst: ask6155: I moved it to drm/nouveau and left a comment
12:19ask6155: Did you also look at dmesg? There were some errors there which I don't think are related. Maybe I should make a different issue?
12:21karolherbst: could be related
12:23ask6155: Is there something else I can do?
12:24karolherbst: not sure... imirkin might have some ideas
12:24karolherbst: ask6155: do you have other connectors you could use?
12:25karolherbst: would be interesting to know if it only happens with one connector type or with all of them
12:25karolherbst: and at least it might give you a good enough workaround
12:26ask6155: I have hdmi dvi and vga on the gpu but unfortunately my monitor only accepts vga
12:26karolherbst: ahh :/
12:27ask6155: if there is anything I can do or should do please just write it in the chat I'll look at the chat logs later.
12:38Gdr-: Hi, sorry if this was already answered before, but I couldn't find anything on it. I'm currently running a gt730 (One built on the fermi architecture, so NC0), and the fan speed it stuck at 100%. According to the feature matrix "fans cannot be managed with Nouveau's hwmon interface". Is there any other place that's able to control it?
12:39Gdr-: Small typo, "it" should be "is"
15:15tertl3: i finally decided to use display port over hdmi
20:47pmoreau: karolherbst: Does `test_basic kernel_preprocessor_macros` from the OpenCL CTS work for you? I’m getting “ERROR: __IMAGE_SUPPORT__ defined to value 1461564976 even though images aren't supported” despite trying to undef that macro or defining it to some other value, but somehow clang seems to be ignoring that.
21:12tertl3: i have a weird question
21:12tertl3: i want to play a movie on the framebuffer in my fullscreen terminal
21:12tertl3: but I get an error when I ask mplayer to do it
21:13tertl3: it said device not found for fbdev
21:13tertl3: but its listed when I check
21:13imirkin: tertl3: permissions?
21:13tertl3: let me run the commands again
21:14tertl3: i tried it last night so I forgot the exact error, one sec ill try it again
21:14tertl3: well after yum finishes
21:14tertl3: im getting 5.11.
21:17tertl3: [vo] Video output fbdev not found!
21:18imirkin: ok, well, i've never used the fbdev output
21:18imirkin: good luck
21:19tertl3: oh well, i gu ess it runs on his machine :P
21:22tertl3: i guess it serves me right meddling in things i know nothing about
21:31pmoreau: Yay, I’ll need to debug clang I guess (and build it from source) cause I have no idea what is going on with that `__IMAGE_SUPPORT__` macro; I can try undefining or defining it to whatever value I want, how many times I want, it still ends up as a `#define __IMAGE_SUPPORT__` after compilation (I assume since the `*result = __IMAGE_SUPPORT__` keep on returning random values).
21:33pmoreau: At least got two different fixes for one of the tests. I’ll probably look at those shared memory errors next since they are quite common.