00:53imirkin: skeggsb_: did that seem approximately right?
02:13sedrosken: was GK208 one of the ones that have reclocking support?
02:14sedrosken: oh, good
02:15imirkin: well, it's a pretty crappy gpu if you're looking to do any serious gaming
02:15imirkin: irrespective of what driver you use -- the hw just isn't there.
02:15sedrosken: "serious gaming"
02:15sedrosken: im a linux user, we don't do those things :)
02:15imirkin: that's what i keep telling people
02:15sedrosken: spoken with tongue firmly in cheek
02:15imirkin: and yet they come and tell me things like "GL compositor"
02:16sedrosken: it's mostly a display adapter to take over from the awful, awful Q35 integrated graphics on my C2Q machine
02:16imirkin: well, should beat the socks off a Q35, reclocking or not
02:17imirkin: that's gen3 pineview or whatever, right?
02:17sedrosken: its low power, low price, and decent performance, particularly in video decoding made it an excellent buy
02:17sedrosken: and if it just so happens to be quicker than the 9600GT it replaced in all regards while it's at it, that's just another win IMO
02:17imirkin: well, the GK208 has the advantage of 10 years of development on it
02:18sedrosken: ten? the 9600GT was that old at the time of release?
02:18imirkin: i meant the Q35
02:18sedrosken: oh, oh
02:18imirkin: for the 9600GT probably more like 6
02:19sedrosken: it probably manages to run about neck and neck with a 9800GT, I'd say
02:19sedrosken: has the advantage of much more (and much faster, in my case) VRAM
02:19imirkin: 9600GT = Feb 21, 2008... GK208 was what ... 2013 i think?
02:19imirkin: or 2014
02:20sedrosken: the 9600GT in question was a G94 I think?
02:20imirkin: yeah that's common
02:20imirkin: it'll depend on whether the GK208 has DDR3 or GDDR5 vram
02:20sedrosken: 2GB GDDR5
02:21imirkin: with GDDR5 it'll be a clear win, i think
02:21imirkin: not to mention lower power consumption
02:21sedrosken: it happens to be low-profile, so it generates a fair amount of heat, idling at 46 according to sensors output
02:21imirkin: either way, you'll want kernel 4.10 or newer
02:21sedrosken: 4.11.7 here
02:21sedrosken: void is pretty cool
02:21imirkin: so then just echo the perf level to /sys/kernel/debug/dri/0/pstate
02:22imirkin: (manual only for now)
02:22sedrosken: it seems to provide more of a sanity-check to arch's push upstream NAO philosophy
02:22sedrosken: seems, to, in my opinion
07:25pmoreau: karolherbst: What was it you needed to add to the kernel cmdline if you encounter "PCI init failure" when trying a nvapeek as root? I thought it was "iommu=relaxed", but it didn't help.
09:29karolherbst: pmoreau: iomem=relaxed
11:02pmoreau: karolherbst: Ah, thanks!
13:47imirkin_: skeggsb_: little oopsie in the disp->chan array size :)
13:54vsnrain: Hello. Not sure if right place to ask, sorry if missed something.
13:55vsnrain: I have problem setting up external monitor on my GeForce 9400M
13:55imirkin_: is that a NVAA or NVAC or something else entirely?
13:55imirkin_: lspci -nn -d 10de::300
13:56vsnrain: with low resolution it works ok, but if you switch to more than 1024x768 it starts flickering a lot
13:56vsnrain: I've read that it may be something to do with performance mode switching
13:57vsnrain: I've recorded it, if it helps somehow https://www.youtube.com/watch?v=v_MlCoqWbLA
13:57pmoreau: Probably NVAC
13:58imirkin_: helps to get the exact info
13:59vsnrain: It is "02:00.0 VGA compatible controller : NVIDIA Corporation C79 [GeForce 9400M] [10de:0863] (rev b1)"
13:59imirkin_: vsnrain: ok, so have you tried increasing the perf level?
14:00vsnrain: no, how do I do this?
14:00imirkin_: cat /sys/kernel/debug/dri/0/pstate
14:00imirkin_: put the results in a pastebin
14:00imirkin_: and give a link to that pastebin
14:02imirkin_: vsnrain: well, you have reasonably high clocks already. but you can try switching to highest and hope it helps -
14:02imirkin_: echo 0f > /sys/kernel/debug/dri/0/pstate
14:06vsnrain: with 0f it flickers a little bit less, but still unusable
14:06vsnrain: forgot to mention, with proprietary nvidia driver it works ok
14:08vsnrain: and if I put refresh rate 30MHz it stops flickering, but colors look like burned and it lags like slideshow
14:12imirkin_: what resolution are you trying to drive?
14:17imirkin_: hm, that should be fine
14:21vsnrain: on last power state, with laptop screen disabled, without moving anything it almost does not lag
14:22vsnrain: *on 1920x1080, lags heavily if I try to move windows though
14:31imirkin_: pmoreau: on a percentage scale, how done is your spirv -> nv50 ir stuff?
14:31imirkin_: (ignoring the clover bits of it)
14:32vsnrain: imirkin_: so is there something else can be done to fix 1080p outopt, or I'm out of luck?
14:33imirkin_: vsnrain: unfortunately i haven't heard of this issue before
14:33imirkin_: this is unfortunate both because i'm not sure how to help, and also because it makes it less likely that others have run into the issue
14:33imirkin_: (otoh i have the memory of a goldfish, so perhaps someone did mention and i just plain forgot)
14:33vsnrain: imirkin_: ok, thanks
14:34imirkin_: vsnrain: the NVAC chip (which is what you have) is an IGP - it doesn't have its own VRAM
14:34imirkin_: this means that such matters could also be affected by your system RAM
14:36vsnrain: well, I have pair of PC3-8500S (1066Mhz) which is already max of what my system supports
15:01pmoreau: imirkin_: Hum... I should have most of the memory management done. Missing is most of the arithmetic operations, making it work for vectors (shouldn't be too hard), and all the event stuff. I'll have a look at which SPIR-V ops I am missing tonight and I'll tell you.
15:02pmoreau: imirkin_: Maybe around 50%, difficulty-wise?
15:15imirkin_: event stuff?
15:15pmoreau: For example in https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/async_work_group_copy.html
15:16pmoreau: You start asynchronous tasks from the GPU
15:16imirkin_: that's not spirv though
15:16pmoreau: Not, but you do have event types in SPIR-V as well
15:17pmoreau: I think that function exists in SPIR-V as well, one sec
15:18imirkin_: i wonder what that does.
15:18imirkin_: i see.
15:18pmoreau: I need to look at what NVIDIA does for that
15:18imirkin_: it's basically you allocate a barrier
15:18imirkin_: and then you can wait on that barrier
15:18imirkin_: or something
15:18imirkin_: [for maxwell+ at elast]
15:18pmoreau: I guess
15:19pmoreau: And of course there is all the GPU-side enqueueing of kernels, but that is an OpenCL 2.0 feature, so I don't feel too bad taking my time to support it.
15:20imirkin_: no worries, i was just curious about general status
15:20imirkin_: how's e.g. control flow?
15:21pmoreau: I am still getting doubts about going with SPIR-V, rather than LLVM IR, as upstreaming of the LLVM IR to SPIR-V pass does not seem to be making that much of a progress.
15:22karolherbst: why not both? :p
15:22pmoreau: if/else/switches should be fine. For loops, I still have that issue in RA where it failed to detect it couldn't reallocate one of the registers.
15:22imirkin_: right, ok. i need to look at that one.
15:22pmoreau: karolherbst: :-p Cause I don't have unlimited time? O:-)
15:22karolherbst: pmoreau: change it :p
15:23pmoreau: imirkin_: I think, at least, during the live_in/live_out computation phase, we need to loop until reaching a fixed point rather than once, or maybe just start from the end of the program rather than the beginning.
15:23imirkin_: pmoreau: i need to look at that logic very carefully.
15:23pmoreau: karolherbst: Or find people to help me ;-)
15:24karolherbst: pmoreau: that sounds like a solid plan to me
15:25pmoreau: Otherwise, if you want something less boring than RA, there is the XCOM bug on Maxwell, which is solved with "MESA_DEBUG=flush": https://bugs.freedesktop.org/show_bug.cgi?id=100177
15:25Efelante90: Hello everyone!
15:25imirkin_: pmoreau: hehe, that's the sort of bug that's very annoying.
15:26pmoreau: But compared to debugging RA? :-)
15:26ccaione: imirkin_: thank you for https://bugs.freedesktop.org/show_bug.cgi?id=101601 I was wondering if you are going to upstream the patch for the heads
15:26pmoreau: Efelante90: Hi
15:26Efelante90: Could anybody say whether nouveau supports Tegra K1 and X1?
15:26imirkin_: ccaione: well, it's a little risky since it changes behavior on a whole swath of boards. i'd want Ben to OK it first
15:26karolherbst: Efelante90: it does
15:26ccaione: I see, yup, sounds good
15:27imirkin_: ccaione: the fix to the # of chans is pretty obvious though
15:27ccaione: yeah, nice finding
15:28imirkin_: ccaione: unfortunately to get accel you'll need firmware... you could try just using the gp107 firmware and hoping it works
15:28imirkin_: i have no clue what's different about each gpu's firmware package
15:28ccaione: for now what we need is just modesetting
15:29imirkin_: although ... given how you did the 0x138 bringup, you might actually be getting the gp107 firmware already
15:29imirkin_: and that fails to load, so ... you're SOL :)
15:29imirkin_: (because you linked it directly to the nv137_chipset struct)
15:29Efelante90: I asked because Tegra K1 and X1 are in the list here (https://nouveau.freedesktop.org/wiki/CodeNames/) but FAQ says that Tegra chips are not supported.
15:30imirkin_: Efelante90: that's in reference to Tegra 20/30
15:31Efelante90: imirkin_: You mean FAQ?
15:32imirkin_: i'm sure the last time that FAQ was modified was a very long time ago
15:32Efelante90: OK, thanks.
15:33Efelante90: Another question. Is there any detailed official documentation from NVIDIA about GeForce chips operation?
15:34imirkin_: they have provided bits and pieces of a couple of minor things
15:34Efelante90: As I understood reverse-engineering is the main way to know it.
15:42Efelante90: Finally, I've saw the status table but anyway what family of chips is supported better by Nouveau?
15:47pmoreau: Efelante90: Kepler, and then probably 1st gen Maxwell and most Tesla cards
15:48Efelante90: OK. And what are the most popular chips in nouveau community?
15:49pmoreau: That I am not sure of
15:50Efelante90: OK, thanks a lot anyway.
15:54Efelante90: I just thought that there may be some simple chip that is supported well by nouveau and can be used as a first chip by the newbie.
16:03noobn: Would i be correct in saying "acceleration will be supporeted in kernel 4.12 for the gtx 1070"?
16:03imirkin_: noobn: depends how you define 'acceleration'. with a sufficiently narrow definition, the answer is 'yes'.
16:04noobn: will there be overclocking?
16:04imirkin_: most definitely not
16:04imirkin_: there won't be reclocking either
16:04imirkin_: so you get the boot clocks, which are extremely low
16:05noobn: re-clockings what i wanted, will it ever happen?
16:05imirkin_: unlikely at this point
16:05imirkin_: esp for desktop GPUs
16:05imirkin_: nvidia has locked things down pretty good
16:05noobn: this ones a mobile
16:06imirkin_: well, with GM20x there's a crazy dance we can do to enable reclocking, but we can't control the fan
16:06imirkin_: on laptops, the fan is usually controlled by the EC anyways, so it's OK
16:06imirkin_: on desktop, not so much
16:06imirkin_: however GP10x changes all the memory reclocking stuff
16:07imirkin_: so ... unclear we'll be able to figure it out
16:07imirkin_: either way, i highly recommend AMD if you're interested in an open experience.
16:07noobn: i though nvidia was helping develop nouveau these days
16:08imirkin_: marketing, mostly.
16:08imirkin_: although they did contribute the secure firmware loader logic for these new GPUs
16:08imirkin_: as well as release firmware to enable basic accel, properly signed and redistributable in the linux-firmware tree
16:08imirkin_: which was nice
16:09noobn: yes kind of them :)
16:09imirkin_: anyways, the developer working on that stuff left a few months ago
16:09imirkin_: they've not announced anyone to replace him
16:10imirkin_: and his job was to primarily make Tegra K1/X1/etc work upstream
16:10noobn: so for number crunching i'm still going to need the proprietary driver then
16:10imirkin_: i recommend AMD :)
16:10imirkin_: [without knowing the details]
16:10noobn: to late for that im affraid
16:11imirkin_: never too late to recommend...
16:12noobn: ok well thanks for the support, i guess i'll have to keep on eye on the development status and keep my fingers crossed
16:12imirkin_: note that nouveau has no support for cuda, opencl, or anything else of the sort
16:13noobn: there are open alternatives now i belive
16:13imirkin_: to nouveau?
16:16noobn: no to cuda someone had written an open cuda implementation for nouveau although i cant find it now
16:17imirkin_: you must be confusing with something else
16:17imirkin_: for example google released a LLVM frontend for CUDA
16:17imirkin_: and e.g. OpenGL compute shaders work fine with nouveau
16:18imirkin_: however there's no glue that goes between OpenCL C and nouveau's compiler IR.
16:18imirkin_: or CUDA CC and nouveau's compiler IR
16:18imirkin_: or PTX and nouveau's compiler IR
16:18imirkin_: or you-name-it and nouveau's compiler IR :)
16:21noobn: i found it https://github.com/shinpei0208/gdev but not quite what i remembered
16:22imirkin_: right, gdev is another thing
16:22imirkin_: and afaik unmaintained
16:23imirkin_: that said, i haven't really played with it
16:23imirkin_: perhaps i should.
16:28noobn: ok i got go thanks
17:10karolherbst: is OP_RET == OP_EXIT basically or is there a fundamental difference?
17:28imirkin_: karolherbst: they're quite different
17:29imirkin_: karolherbst: OP_RET will pop the call stack and jump
17:29imirkin_: while OP_EXIT will terminate the thread
17:29imirkin_: OP_RET is the counterpart to OP_CALL
17:29karolherbst: and what happens if you do ret within the main function?
17:29imirkin_: STACK_ERROR? :)
17:29imirkin_: i dunno, it might actually just exit
17:29karolherbst: that one F1 shader does exacty this
17:29imirkin_: oh wait
17:30karolherbst: 426.shader_test in the repository
17:30imirkin_: OP_PRERET specifies where ret goes
17:30imirkin_: not call.
17:30imirkin_: or maybe either oen.
17:31karolherbst: okay, seems fine then
17:31karolherbst: preret BB:1 .... ret and BB:1 has an exit instruction
17:31imirkin_: assuming we don't fuck that up somehow
17:31karolherbst: actually I don't think it's the fault of the compute shader
17:32karolherbst: because every call after invoking it doesn't lead to any timeouts
17:32karolherbst: just the next draw does
17:33karolherbst: except I miss something
17:33karolherbst: (like knowledge about how compute shader work)
18:08karolherbst: the hell is wrong with that fragment shader :O
18:09karolherbst: the computer shader is a joke compared to that
19:07imirkin_: karolherbst: i think the issue is a shader that depends on some previous shader setting something in a ssbo which gets messed up, and causes an infinite loop in that shader
19:07imirkin_: karolherbst: do test with the fixes that i pushed earlier this week, on the off chance that they help
19:07imirkin_: however that seems unlikely.
20:08pmoreau: imirkin_: If you want some stats for SPIR-V opcodes support: https://phabricator.pmoreau.org/w/mesa/spirv_support/
20:08pmoreau: imirkin_: It is missing all OpenCL and GLSL specific opcodes though, and it does not track unsupported decorations and builtins, for example.
20:11karolherbst: imirkin_: on your cts branch?
20:12karolherbst: ohh on master actually
20:21imirkin_: karolherbst: yeah master now
20:24karolherbst: getting silly errors on master: "../../../src/mesa/main/marshal.c:484:4: error: implicit declaration of function ‘CALL_NamedBufferSubData’ [-Werror=implicit-function-declaration]"
20:57karolherbst: imirkin_: 95fb1c187a0ea8d13f401145282363228b91b246 broke it
22:55imirkin_: skeggsb_: mornin'