00:01 karolherbst: it should work though, just untested (tm)
01:00 Manoa: thank :)
16:56 c_nix: do acceleration on NVS310 works?
16:58 imirkin: remind me what GPU that is?
16:58 imirkin: (lspci -nn -d 10de: )
16:58 karolherbst: probably a fermi
16:59 c_nix: u,m its 2012 year
16:59 c_nix: wiki says fermi
16:59 karolherbst: c_nix: are you planning to buy one or why the question?
17:00 c_nix: I own one and I think about puting it into computer
17:00 karolherbst: ahh
17:00 karolherbst: yeah, if it's a fermi it should work alright
17:00 karolherbst: hopefully
17:00 c_nix: great, thanks will test in few days
17:00 karolherbst: just... very slow
17:00 karolherbst: so not sure how much of "acceleration" you can expect
17:01 karolherbst: it's a low power card to begin with
17:01 karolherbst: and we can't relibly change clocks on fermi
17:01 c_nix: too be honest aall i need is to run ioquake3 on it at best
17:01 c_nix: ;)
17:01 karolherbst: that might be too much
17:01 c_nix: xd
17:01 karolherbst: it's really a slow card
17:01 c_nix: keplers are better on that regard?
17:01 karolherbst: yeah
17:01 karolherbst: reclocking on kepler works in most cases
17:01 c_nix: great they are cheap here
17:02 c_nix: NVS 510 would do?
17:02 RSpliet: Well, not all keplers are made equally
17:02 karolherbst: c_nix: well.. if you want to buy one, you might just buy a GPU with vendor supported drivers though
17:02 c_nix: whatever I need just multiheaded display for terminals mostly running open arena is just a bonus - nice if I can but no cry if I cant
17:02 karolherbst: nouveau is all "best effort"
17:03 karolherbst: and if you run into bugs there might or might not be somebody fixing it
17:03 karolherbst: so it's a little risky
17:03 karolherbst: but you can already try with the one you have and see if it is good enough
17:03 karolherbst: I just don't want people to encourage buying something they wil be unhappy with, because random stuff is broken
17:04 c_nix: i was working as a kernel dev for a while, I may use few tricks just in case xD But as I said all I *need* is 2d output
17:04 karolherbst: ahh yeah. And there is some experimental code to reclock on fermi as well
17:04 karolherbst: might work for you
17:04 karolherbst: maybe not
17:05 karolherbst: would be cool to get that into better shape though
17:05 c_nix: will see, In worst case I may try hacking some stuff xD
17:05 RSpliet: c_nix: you'll get 2d and 3d on the NVS 310. If you have a looooooot of patience and time you can help make it faster (by implementing that clock changing stuff)
17:06 c_nix: RSpliet: I have plenty of free time so why not
17:06 RSpliet: We have someone else here who recently showed interest in that too. Not sure if he's still here or gave in, but may have made some progress in forward porting an old half-finished branch
17:07 c_nix: RSpliet: do I need to do any interfacing with card itself by some interfaces outsice matherboard?
17:07 c_nix: for such work
17:07 c_nix: *potentially*
17:08 RSpliet: c_nix: I did this stuff for 2nd gen Tesla. Didn't need any external tools, just tons and tons of patience
17:08 c_nix: >inb4 if you ask such think you are too lame to play with that
17:08 c_nix: ok
17:08 RSpliet: TL;DR: the biggest challenge with clock changing is changing the DRAM timing parameters on the memory controller side
17:08 c_nix: RSpliet: so set some values, recompile and see if it's stable for a while?
17:09 RSpliet: Values are dictated by the video BIOS, but we don't quite know what value maps to what bit of what register
17:09 c_nix: (and pray you don't fry stuff)
17:09 RSpliet: So a lot of the work is "slightly alter one parameter, observe the differences in register writes compared to baseline, implement that one bit"
17:09 c_nix: RSpliet: maybe there are any interesting materials to read on that?
17:09 RSpliet: rinse, wash, repeat ad infinitum
17:10 c_nix: I get the picture
17:10 RSpliet: c_nix: it's hard to fry a card. It's easy to lock one up though, so plenty of reboots involved.
17:11 RSpliet: DRAM has some resilience, esp in lower clock modes, but at some point you want the high speed goodness and getting all the deets out will prove tedious ;-) and your feedback isn't "some pixels are slightly off" but rather "it works/it locked up"
17:12 RSpliet: Reading materials hmm... well, the envytools' nvbios tool contains some code that reads out DRAM timing parameters. Gives you a bit of a feel for the data structures inside the VBIOS
17:12 c_nix: great, sounds like reasonable starter
17:13 RSpliet: I'm proud of nouveau's NVA3/5/8 code obviously :-P but the Kepler code is very useful too (if not slightly more).
17:14 RSpliet: nvkm/subdev/fb is where such code currently lives
17:15 RSpliet: ramgt215.c is pretty much dedicated to the RAM side of reclocking for 2nd gen Tesla, ramgk104.c is for Kepler, ramgf100.c is where your code will go ;-)
17:15 RSpliet: Don't worry, a lot of forework has been done, one old branch for that is https://github.com/skeggsb/nouveau/tree/devel-clk/drm
17:16 RSpliet: my earlier efforts live in here https://github.com/RSpliet/kernel-nouveau-nv50-pm/commits/master - the two branches aren't compatible with each other, these were parallel efforts
17:17 ccr: I just put a NVA8 GT 210 into one of my machines to test it out. almost immediately ran into https://gitlab.freedesktop.org/drm/nouveau/-/issues/14 though I didn't get a lock-up at any point, just those errors in klog and extreme slowness with "mpv --vo=gpu". :) thought that I'd found a good way to reproduce, but after reboot I couldn't get it to trigger.
17:18 imirkin: ccr: that's a modesetting error
17:18 imirkin: i.e. an error while changing modes
17:18 ccr: interesting. it did occur only with fullscreen video. tho.
17:18 imirkin: (or doing other things to the display engine)
17:19 imirkin: depending on your env, that could cause a flip to mpv's image? dunno
17:19 imirkin: maybe some parameters were wonky
17:19 imirkin: would need the display state
17:20 ccr: is there anything in debugfs or proc in case I hit it again?
17:22 karolherbst: could just be pushbuffer corruption though
17:22 imirkin: ccr: no.
17:22 imirkin: there may be stuff in dmesg
17:22 imirkin: like a dumped error state
17:22 imirkin: which would be fine
17:23 imirkin: but sometimes the hang happens and there's no further info, so you have to work it out from stuff that was submitted
17:23 ccr: okay. didn't see anything like that myself.
17:23 imirkin: there's a drm.debug=... which is super-verbose for it (or maybe nouveau.debug)
17:23 ccr: seems to be rather randomly occuring issue in any case
17:24 ccr: e.g. annoying to reproduce
19:07 ignapk: I'm still here :) haven't made much progress but I'm still interested in helping with that fermi re-clocking
19:14 ignapk: one idea I never had time to test was trying to use only the nvidia gpu instead the optimus technology but I couldn't find any information how to do that (without properietary driver ofc)
19:16 karolherbst: ignapk: usually developing on prime system is a bit easier as you don't take down X
19:16 karolherbst: you can make X ignore your secondary GPU
19:16 karolherbst: or just boot with nouveau.modeset=2
19:17 karolherbst: then you can use intel as your X server and the nvidia GPU is there doing nothing except you do DRI_PRIME=1 offloading
19:17 ignapk: yeah this was just a guess since I run into a bug when trying to reclock without the card running already by some process in the background
19:18 ignapk: it already does that: I can do the offloading, I just thought that if I somehow disabled the integrated intel gpu I would get more luck with re-clocking
19:19 ignapk: but hey, I'm still happy I managed to downclock successfully :D take that nvidia
20:53 TimurTabi: I think I asked this before but I don't remember the answer. Does anyone have a very easy to download/compile command-line performance test for Nouveau? For example, something that multiples a million matrices or something and prints out the time it took.
20:55 ignapk: TimurTabi: in case you don't know it I usually just test with glmark2
20:57 TimurTabi: doesn't that require graphics?
21:00 TimurTabi: I only have ssh access to the machine
21:01 HdkR: Run an offscreen xserver?
21:01 TimurTabi: I don't know what that is
21:01 TimurTabi: do you mean with the --off-screen parameter?
21:02 TimurTabi: If so, are these good results:
21:02 TimurTabi: $ glmark2 --off-screen
21:02 TimurTabi: ** GLX does not support GLX_EXT_swap_control or GLX_MESA_swap_control!
21:02 TimurTabi: ** Failed to set swap interval. Results may be bounded above by refresh rate.
21:02 TimurTabi: =======================================================
21:02 TimurTabi: glmark2 2014.03+git20150611.fa71af2d
21:02 TimurTabi: =======================================================
21:02 TimurTabi: OpenGL Information
21:02 TimurTabi: GL_VENDOR: VMware, Inc.
21:02 TimurTabi: GL_RENDERER: llvmpipe (LLVM 8.0, 256 bits)
21:02 TimurTabi: GL_VERSION: 3.1 Mesa 19.0.8
21:02 TimurTabi: =======================================================
21:02 HdkR: ack
21:02 TimurTabi: ** GLX does not support GLX_EXT_swap_control or GLX_MESA_swap_control!
21:02 TimurTabi: ** Failed to set swap interval. Results may be bounded above by refresh rate.
21:02 TimurTabi: [build] use-vbo=false: FPS: 491 FrameTime: 2.037 ms
21:02 TimurTabi: ** GLX does not support GLX_EXT_swap_control or GLX_MESA_swap_control!
21:02 TimurTabi: ** Failed to set swap interval. Results may be bounded above by refresh rate.
21:02 TimurTabi: [build] use-vbo=true: FPS: 550 FrameTime: 1.818 ms
21:03 HdkR: If you're pasting a large number of lines, use a paste service
21:03 HdkR: and you can see in their results that this is running llvmpipe rather than nouveau
21:03 TimurTabi: how do I fix that?
21:07 HdkR: eeeh. You're not in a sane graphical setup
21:09 Lyude: imirkin: saw your email about the xorg issues btw, will take a look the next chance I get
21:16 ignapk: a very good paste service is https://paste.rs btw
21:24 imirkin: Lyude: cool. i suspect it's issues you've already fixed, but not in that version? dunno.
21:24 imirkin: Lyude: i.e. broke and then fixed, and they're in the broken state
21:24 Lyude: maybe, i've got some work to do on that still but i'm pretty sure i've fixed any regressions I introduce
21:24 Lyude: *introduced
21:25 TimurTabi: Ok, I managed to connect to the system via RDP, but it still says the rendered is llvmpipe
21:25 TimurTabi: How do I set the renderer to Nouveau?
21:25 Lyude: also update on igt stuff: nvidia gave us a way of making the primary plane appear black without having it set to a valid FB (apparently they use an all-zero CSC matrix in the blob to do this, which is much nicer then us having to zfill an empty fb every time we want to do this
21:27 imirkin: clever.
21:34 Lyude: hm, although I just noticed they still reject flip requests that would result in a surface in overlay without a surface in base. hopefully that's just the blob being overly cautious
21:34 Lyude: but i guess worst case scenario if we need to allocate an fb anyway it wouldn't be much of an issue, since we wouldn't even need to write to it
21:39 imirkin: Lyude: i'm wondering if the 10bpc stuff is upsetting that particular situation -- it's a 10bpc-capable screen, but i bet that you can't do 4k@60@10bpc over DP? dunno
21:44 Lyude: if it's over mst we're running it at 8bpc
21:45 imirkin: doubt it'd be MST