01:34neur0sis: whois mwk
01:36imirkin: he's a mystery
01:37neur0sis: I just wanted to purpose him a hardware donation
01:37neur0sis: I left him a query
01:38imirkin: you were having hdmi audio troubles, right?
01:38neur0sis: ha wrong one, Martin Peres actually looking for the 107
01:38imirkin: that's mupuf
01:39neur0sis: i have a 1050 gtx if he want it
01:39neur0sis: no hdmi output video problem
01:40neur0sis: with my rtx 2080 ti 11gb
01:40neur0sis: but probably because it really recent hardware
01:41imirkin: with kernel 5.1, i think it's meant to work...
01:41imirkin: what kernel were you on?
01:41neur0sis: it work using modesetting drivers however but xorg freeze after sometime, cannot catch a dam log about whats wrong
01:41neur0sis: I tried to ssh yesterday
01:42imirkin: oh, so it works, but hangs
01:42neur0sis: doesn't even reply to a local ping
01:42imirkin: yeah, that's a different problem than total non-working
01:42neur0sis: surely something wrong on my side anyway
01:42imirkin: maybe the upcoming 5.2 will have some fixes that will help
01:43imirkin: like e.g. https://github.com/skeggsb/nouveau/commit/5856288884c987995aaa735f0e4b9f42f0169318
01:43neur0sis: I will take look
01:43neur0sis: could be a fix indeed
01:44neur0sis: NVDisplay could hang forever in some circumstances
01:44neur0sis: yes look like the problem i have
01:45imirkin: well, "things hang" isn't like a singular issue. could be anything that causes it.
01:45imirkin: but the fix is for an issue which causes hangs. could be 100 other such issues though :)
01:45imirkin: (you can tell - i'm an optimist)
01:46neur0sis: could be, without a trace hard to find whats wrong
01:51neur0sis: I'm unsure about it but using two GPU, one rtx 2080 ti and one 1050 TI with a i3 3.60GHz 8th can be a problem ? Like the CPU enought powerfull to handle properly.. ?
01:51imirkin: highly unlikely to cause issues
01:51neur0sis: alright I saw this on stack,wasn't sure about it
01:52neur0sis: "Intel i7-5820K can't handle two x16 graphics cards."
01:53neur0sis: pci 0000:01:00.0: 32.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s x16 link at 0000:00:01.0 (capable of 126.016 Gb/s with 8 GT/s x16 link) <--- my log
01:54neur0sis: Im limited because of my cpu ?
01:56imirkin: cpu doesn't have infinite PCIe lanes
01:56imirkin: but it all degrades gracefully
01:56imirkin: assuming the power is there, you can run it on PCIe x1
01:58neur0sis: alright, will plan to get a better cpu then, thanks
01:59imirkin: doubt it'll matter
01:59HdkR: You'll have a hard time bottlenecking an x8 connection with a consumer workload
02:00imirkin: esp PCIe v3
02:00HdkR: Even the crazy 4x GPU DGX-Station can't run all its GPUs at x16 connection
02:02HdkR: You would need a dual-CPU, threadripper or EPYC to to ensure full x16 for everything :)
02:10neur0sis: I'm sticking with intel had a bad experience with amd, ryzen 3 i guess, ubuntu was crashing all time and couln't install a gentoo system without getting segfault with gcc, kind of error I never had with intel
02:10neur0sis: similar to this one https://forums.gentoo.org/viewtopic-t-1061546.html
02:11neur0sis: I tried with a native cflag and optimized one, still
02:11neur0sis: however it work nicely on windows so I don't think it is a hardware issue
02:15neur0sis: afk, will be back around monday, see u
11:59peteris: I have a question about submitting a patch for nouveau Linux kernel module.
11:59peteris: Which kernel tree should I use to prepare the patch?
11:59peteris: Should I use this one: https://github.com/skeggsb/linux ?
12:02soreau: probably https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
12:04peteris: Ok, thanks for the info. Should I prepare it against master branch? I am new to kernel development process, so forgive me if it is a dumb question.
12:05soreau: Generally you want git master unless you have a specific target
12:06peteris: Yeah, I read that submitting patch guide. That is where I got the advice to check MAINTAINERS file, which lead me to the github repo.
12:10soreau: I see, well I guess you'd create it against the one you mentioned and send it to the nouveau mailing list (with git send-email)
16:39imirkin: peteris: https://github.com/skeggsb/linux is the current upstream repo. unfortunately it's master branch is unmaintained, so you have to guess which branch is the latest (should be pretty obvious)
16:39imirkin: skeggsb: you should definitely fix the master branch on there...
16:39imirkin: it's quite confusing
16:41imirkin: either make it point to the same thing as whatever the latest one is, or delete it entirely and make the latest the default branch (but then you have to keep updating it)
16:48imirkin: karolherbst: 1ULL << shift, not 1LL. otherwise various complainers complain about stupid things like "is 1LL << 63 defined?" (duh, of course it is, but ... they are complainers who complain.)
16:52peteris: imirkin: the outdated master branch is indeed what confused me. Thanks for clearing that up.
16:53imirkin: what sort of change are you doing?
16:55peteris: It is a oneline bug fix in drivers/gpu/drm/nouveau/dispnv50/head.c
16:56imirkin: there are a handful of changes in ben's private repo as well, to display things, but they're all also 1-line fixes
16:56imirkin: you can see them here: https://github.com/skeggsb/nouveau/commits/master
16:57imirkin: doesn't matter which repo you do the patch against, skeggsb will be able to transpose it either way.
16:57imirkin: thanks for contributing :)
17:01peteris: Now I'm trying to figure out whom should I send the patch to. Does sending to Ben Skeggs and cc to firstname.lastname@example.org and email@example.com sounds reasonable?
17:01imirkin: (and nouveau@ obviously)
17:02imirkin: i personally don't send those patches to linux-kernel@, but ... no harm done if you want to
17:03imirkin: i dunno what the official position on this stuff is, tbh. unless the patch is "rewrite nouveau", it's not very important to get the wider audience
17:03peteris: So to Ben and cc firstname.lastname@example.org and email@example.com?
17:03imirkin: that's what i do.
17:03peteris: Ok, I'll try that. Thanks!
17:13imirkin: skeggsb: the condition to handle DRM_MODE_SCALE_ASPECT appears broken... it checks for oH < oW to determine whether to recompute oW or oH
17:13imirkin: skeggsb: but shouldn't it be comparing the aspect ratios?
17:14imirkin: i.e. compute a rO and rI or whatever, and if one is less than the other, go one way, otherwise the other way
17:14imirkin: as-is, it assumes a square input, which is probably a bit off
17:14imirkin: (i think)
19:46imirkin: peteris: nice find!
19:55imirkin: skeggsb: entirely untested, but i'm thinking this: https://hastebin.com/iyaqopuzep.php
23:01karolherbst: imirkin: huh? what was that related to? the 1ULL << shift... thing
23:15RSpliet: karolherbst: shifting a signed value is apparently contentious, the closest stackexchange I could find claims that shifting negative values is undefined. To be on the safe side, it's probably worth to make it a habit only to shift unsigned values, hence the ULL prefix for 64-bit literals rather than LL
23:15karolherbst: RSpliet: no, I meant, why telling me this?
23:15RSpliet: oh ok, in that case idk
23:16karolherbst: it's probably something dumb I wrote somewhere...
23:16RSpliet: is this not knowledge you desire to have? He might be telepathic :-P
23:17karolherbst: I am sure I wouldn't say that 1LL << 63 is undefined? maybe I have? maybe I just change my mind without knowing it? I don't know
23:17karolherbst: there was a comment I left regarding a 32 bit fail, but I doubt it was related to it
23:17karolherbst: espeically because I wrote "this has to be 1ull. "
23:17karolherbst: (instead of 1ul)
23:21Habbie: 1ull is very hard to read in lowercase
23:21Habbie: is all i have to add to this :>
23:21RSpliet: idk, he might've bumped into a patch on a random ML or w/e. I just duly noted his remark next to some other useful pieces of life advice like "assert for programmer errors, exceptions for user errors" and "always bring your towel"
23:24karolherbst: ohh, I have an idea
23:24karolherbst: found it
23:25karolherbst: imirkin: yeah, thanks for pointing it out, this should be fixed
23:46imirkin: karolherbst: sorry, that comment could have been clearer
23:47imirkin: you had a 1ll << i in your code
23:47karolherbst: yeah, I found it
23:47karolherbst: no idea what I was thinking back then
23:47imirkin: compiler writers / language lawyers argue that 1ll << 63 is undefined, since numerical storage isn't guaranteed to be 2's complement
23:47imirkin: imo that's a load of bs, but ...
23:50karolherbst: yeah.. in that case using 1 ull makes more sense anyway
23:53imirkin: btw, what's the upshot of your latest opencl series?
23:53imirkin: can you run CL 1.1 with that?
23:53karolherbst: well, tons of builtins are still missing
23:53karolherbst: but airlied is working on that
23:53karolherbst: aka porting libclc over to spirv
23:53karolherbst: but yeah, essentially yes
23:53karolherbst: a lot of the opencl cts 1.2 stuff is passing
23:54imirkin: right, need a clc of some sort
23:54karolherbst: imirkin: on iris: https://people.freedesktop.org/~airlied/piglit/clres/cl/index.html
23:55karolherbst: nouveau should yield similiar results
23:55karolherbst: imirkin: the biggest issue left to solve is consuming unstructured spirv, right now we use a hacky way on structurizing the spirv when it comes out of spirv-llvm-translator
23:55karolherbst: so we need a proper solution for that
23:56imirkin: llvm has a structurizer i thought
23:56karolherbst: I have some WIP stuff on this though, essentially building a unstructured nir with goto_if instructions and then convert it to the loop/if structures
23:56karolherbst: imirkin: 2.1 requires consuming spirv directly
23:56karolherbst: but yeah, we could structurize the llvm before converting
23:57karolherbst: and that's what we do right now for development
23:57imirkin: well, just thinking path of least resistance
23:57karolherbst: and we already have that :) we just patched spirv-llvm-translator to structurize the spirv
23:57imirkin: eventually you need to handle the real thing, but it's not like there are any serious applications that need this today
23:57imirkin: anyways, cool
23:58karolherbst: right.. but doing this inside nir isn't that much of a problem. We just assume that the spirv we get is more or less structurable without having to move blocks around or copy blocks
23:58karolherbst: we just need to do that properly
23:58karolherbst: might take some days of work
23:58karolherbst: my WIP patches already works for nested loops and ifs
23:58karolherbst: and a lot of the OpenCL CTS stuff