01:21 orbea: heh, lot of nouveau changs in 4.8rc1
08:27 karolherbst_work: mupuf: can you comment on the backlight thing why he uses a curve? I would _much_ rather have the full scale exposed to userspace, and userspace should come up with nice curves itself
08:27 karolherbst_work: (don't know my login things, would have to drive home for that :p )
09:22 mupuf: karolherbst_work: talking about https://bugs.freedesktop.org/show_bug.cgi?id=31122?
09:30 karolherbst_work: yeah
09:31 karolherbst_work: we should always expose the full range to userspace and don't try to be smart in the driver
09:32 karolherbst_work: especially with old displays, they are so messed up, that the user might to have a custom curve anyway
09:34 karolherbst_work: also "nvif_wr32(device, NV30_PMC_BACKLIGHT, (NV30_BL_CURVE[val] << 16) + 0x80000535);" this part is oddish
09:34 karolherbst_work: why the "0x80000535" ?
09:34 karolherbst_work: is it to protect from "too dark" displays?
09:34 karolherbst_work: if yes, then annoying things like that shouldn't be done too
09:35 karolherbst_work: well, 0x80000000 being commit obviously, but the 0x535 part
09:36 karolherbst_work: mhh
09:38 karolherbst_work: I think I will make a more thorough today, there are a lot of things I am really not happy about :/
09:40 karolherbst_work: or am I wrong with the point to expose the full range? Intel also does it and I don't see why we should do anything else.
09:49 karolherbst_work: mupuf: I managed to login :D
09:51 mupuf: I agree that the userspace should handle this ... but he may not want to fix all the userspace apps
09:51 karolherbst_work: they are fixed already
09:51 karolherbst_work: at least I know that xfce, kde4 and plasma5 can handle that
09:51 karolherbst_work: intel really exposes like 2000+ brightness levels on some hardware
09:52 mupuf: yep
10:06 karolherbst_work: done :)
10:06 karolherbst_work: I should review code more often, but somehow I don't find anything too say usually :/ I guess you are all that good
10:12 karolherbst_work: mupuf: even mac os x has 64 brightness levels in total, no idea how he gets to 8, but I guess his userspace thingy was odd or nvidia is odd
10:46 mupuf: 8 is really not a lot
11:03 pq: karolherbst_work, if you find nothing to say about a patch you review, then say Reviewed-by: ;-)
11:16 karolherbst_work: :D
11:17 karolherbst_work: but if I don't find anything, I feel not good enough to review it, cause I didn't catch the errors in it :p
11:35 pq: karolherbst_work, if everyone thought like that, nothing would ever get landed
11:36 pq: karolherbst_work, and if you stay silent, your reading effort will be wasted as no-one will know that it looked ok to you.
11:44 karolherbst_work: pq: mhh, true
11:45 mupuf: karolherbst_work: then Acked-by
11:46 karolherbst_work: right
11:46 pq: mind that kernel Acked-by means something very different from what other projects usually use
11:46 karolherbst_work: huh?
11:48 pq: see kernel's SubmittingPatches
11:48 karolherbst_work: what can acked-by mean besides "I am okay with it"
11:48 pq: ^
11:49 karolherbst_work: k, so the normal stuff
11:49 pq: I would interpret the definition there as "stronger that Reviewed-by for the parts you are a maintainer of".
11:49 karolherbst_work: I wouldn't say so
11:50 karolherbst_work: "Reviewed-by" also means that _you_ fix the code, if every other contribute vanished into thin air
11:50 karolherbst_work: "acked-by" doesn't state this
11:50 karolherbst_work: *contributor
11:50 pq: "often used by the maintainer" and "has at least reviewed the patch" - it says "reviewed"
11:51 karolherbst_work: and?
11:51 karolherbst_work: read the reviewed-by part :p
11:51 pmoreau: I always thought Reviewed-By was stronger than Acked-By, at least for Mesa
11:51 pq: pmoreau, for Mesa, yes
11:51 pq: pmoreau, only the kernel is of question here
11:52 pmoreau: And it’s the opposite in for the kernel? Interesting. I’ll have a look at the document you mentioned
11:52 pq: pmoreau, note: this is my personal interpretation and I have not done kernel work in years.
11:54 pq: if I have misinterpreted SubmittingPatches, that would be very welcome to me
11:55 pq: karolherbst_work, where does it say "you fix the code..."?
11:59 karolherbst_work: pq: there was a discussion once about that, no idea when though, I just remember it was consensus at that time
12:00 pq: heh
12:01 karolherbst_work: but that goes without saying usually, because if you add a rb, you have reviewed it that much, that you are actually also possible to fix the code anyway
12:01 karolherbst_work: otherwise the rb would be pretty worthless
12:06 pq: capable probably, committed or able is another question
12:10 karolherbst_work: mhh, right
12:11 karolherbst_work: but in the end it doesn't matter, because if Linus noticed, that you acked/rb something you should know is bad, you get your nasty response anyway
12:11 karolherbst_work: :D
12:21 mwk: well, the hammer has fallen
12:28 karolherbst_work: :D
12:29 karolherbst_work: why? Just because of the enums? :p
12:29 mwk: no... I want classes, actually
12:29 karolherbst_work: ahh I see
12:29 karolherbst_work: allthough I would say we do c++11 and named enums
12:29 karolherbst_work: otherwise enums feel like constants
12:29 karolherbst_work: but that may be too much work actually
12:30 mwk: yeah, enums will come in due time
12:30 karolherbst_work: allthough I really dislike the .cc stuff, feels like windows to me
12:31 karolherbst_work: I prefer cpp
12:31 Calinou: cpp/hpp ftw
12:32 karolherbst_work: well I usually go with the cpp/hpp/h style
12:32 karolherbst_work: and use hpp for templates usually
12:34 karolherbst_work: also cc looks like c extended, which c++ is really not :p
12:34 karolherbst_work: so i automatically assume crappy code in cc files by default
12:35 mwk: that's what it stands for, cc == crappy code
12:35 pmoreau: :-D
12:36 Calinou: therefore, .c is code
12:36 Calinou:runs
12:36 mwk: "uint32_t nv01_pgraph_state::* ptr;"
12:36 mwk: beautiful
12:37 karolherbst_work: :D
12:37 karolherbst_work: the heck
12:37 mwk: C++ pointer to field
12:37 karolherbst_work: alone for using pointers I would ban you from any c++ development :p
12:37 mwk: er, class data member
12:38 karolherbst_work: lambdas, duh
12:38 mwk: it's basically a type-safe offsetof
12:39 karolherbst_work: I am sure with lambdas you get an actually much better design :p
12:40 mwk: ... how would I do that with lambdas?
12:41 karolherbst_work: std::function<const uint32_t& (void)> func = [&] { return o.field } or so
12:41 mwk: ... and corresponding setters?
12:42 karolherbst_work: remove the const
12:42 karolherbst_work: then you can do func() = 5;
12:42 karolherbst_work: :D
12:42 mwk: what, you can actually do that?
12:42 karolherbst_work: course
12:43 karolherbst_work: it is a reference
12:43 mwk: ...
12:43 mwk: true
12:43 mwk: well, fuck
12:43 mwk: it appears I can't do &nv01_pgraph_state::iclip[0]
12:44 mwk: I can only point to actual top-level members
12:44 karolherbst_work: add a*
12:44 karolherbst_work: uint32_t nv01_pgraph_state::** ptr;
12:44 mwk: so it's a type-safe and piss-poor version of offsetof
12:45 karolherbst_work: or so… no clue anymore
12:46 karolherbst_work: but I really dislike that o.field() = newValue; kind of style… looks a bit oddisch
12:46 karolherbst_work: *oddish
17:38 ttr_ppix: was unable to build Karol Herbst's GDDR5 reclocking branch -> http://imgur.com/a/4Zj6y
17:38 ttr_ppix: attemtping to build against mainline 4.6.5
17:40 orbea: ttr_ppix: try this branch https://github.com/karolherbst/nouveau/tree/stable_reclocking_kepler_v5_4.6
17:42 ttr_ppix: orbea, will do, thank you very much!
17:45 ttr_ppix: for the record, the stock kernel on ubuntu xenial (4.4.0-34) loses control of the display/mouse/keyboard when launching steam games in fullscreen, would be happy to collect info and send upstream if it would be useful
17:46 Yoshimo: what is left to do before nouveau exposes OpenGL 4.3 on a maxwellv2 card?
17:46 Yoshimo: gslGLSL 4.30 required for defining arrays of arrays is printed to the terminal when i run Flame in the Flood, is that extension missing for maxwell even though nvc0 supports it on mesamatrix?
17:46 Tom^: ttr_ppix: wouldnt be much useful until you get atleast kernel 4.6.x , mesa 12.1.x
17:47 Tom^: ttr_ppix: reporting bugs on old kernels and mesa versions without even seeing if they still are around on newer ones is pointless
17:47 ttr_ppix: Tom^, sounds good, I'll test on kernel 4.6.5 stock and 4.6.5 with Karol's patch set and report back
17:48 Tom^: ttr_ppix: and mesa 12.1.x
17:48 ttr_ppix: Tom^, currently at mesa version 12.1~git1600808165700.7dfb1a4~x~padoka0
17:48 Tom^: ok good :p
17:49 ttr_ppix: Tom^, just to be clear Mesa 11.2.0-stable is not acceptable?
17:50 Tom^: sure it is :p
17:50 Tom^: oh wait 11.2 nah
17:50 Tom^: the thing is running those old versions you might just see bugs that are already fixed
17:50 Tom^: hence if you find a bug, go up to current see if it still exists and report.
17:52 ttr_ppix: Tom^, appreciate the advice, i'll revert to 11.2.0 and retest with 12.1.x git if it fails
17:53 imirkin: Yoshimo: AoA should be supported on maxwell v2. in order to expose GL 4.3, we need to expose images on maxwell, which in turn requires some instruction scheduling work to be done
17:54 Tom^: imirkin: morning sir, are there reasons for why dri isnt default dri 3 on exa?
17:54 Tom^: or has it just been forgotten :p
17:56 imirkin: fear of the gathering darkness?
17:56 imirkin: afaik people have issues with crazy DE's that i don't care to install on my machine
17:56 imirkin: like gnome or kde
17:57 Yoshimo: imirkin: so that error from my game is wrong?
17:58 imirkin: Yoshimo: well, AoA is part of GL 4.3, so my guess is that they way they enable AoA is by just doing "#version 430", which won't work unless you have GL 4.3
17:58 imirkin: Yoshimo: however if they just wanted AoA, they could also do #extension GL_ARB_arrays_of_arrays: require
18:01 Yoshimo: how complicated is exposing images on maxwell?
18:02 imirkin: Yoshimo: well, that's all done actually. the problem is that we don't provide the proper scheduling info to the instructions
18:02 imirkin: and so some code patterns can hang the shader units
18:02 imirkin: which piglit and/or dEQP actually runs into
18:03 imirkin: hakzsam was going to look into it afaik
18:03 imirkin: Yoshimo: you could just force-enable GL 4.3 and see if that works for the game
18:04 Yoshimo: overriding it in wine didn't make a difference, where else could i fake it?
18:04 imirkin: how did you do it?
18:07 Yoshimo: MESA_GL_VERSION_OVERRIDE=4.3 .wine64 RiverGame.exe
18:07 Yoshimo: 4.3 or 4.3compat , result is the same
18:08 imirkin: you also need MESA_GLSL_VERSION_OVERRIDE=430
18:11 Yoshimo: i'll try that
18:36 ttr_ppix: orbea, thanks again for pointing out the stable tree (https://github.com/karolherbst/nouveau/tree/stable_reclocking_kepler_v5_4.6)
18:36 orbea: heh, I made the same mistake the other day...
18:36 ttr_ppix: it built just fine and i packaged it into a DEB file for convenience
18:37 ttr_ppix: excited to give this a try on actual hardware tonight
19:31 karolherbst: yay, I just gave away my first conditional rb-by :)
19:31 karolherbst: ....
19:31 karolherbst: how do I get to rb-by?
19:33 tobijk: karolherbst: review-ception :o
19:34 tobijk: karolherbst: imirkin: btw do we know how many cycles instructions like mul shift or add take?
19:34 tobijk: is that noted somewhere? :>
19:36 imirkin: tobijk: there's a getThroughput() function in the target
19:36 imirkin: and perhaps a getLatency(). i forget.
19:36 karolherbst: well, it is mainly guessed though I think
19:37 imirkin: i think based on observations of how the blob schedules
19:37 karolherbst: might be, yes
19:37 karolherbst: point is, we don't know for sure
19:37 tobijk: imirkin: i was wondering if shl and add would be faster compared to mul with odd numbers
19:37 karolherbst: (as this would be any different with other stuff :D)
19:38 karolherbst: tobijk: benchmark it
19:38 tobijk: mhm
19:38 karolherbst: pixmark_piano is a good candidate for a non micro benchmark
19:39 karolherbst: 1% less instructions gives around 1% more perf there
19:39 tobijk: it would be two insn for one then
19:39 tobijk: ...
19:39 karolherbst: and changes in the generated code are noticeable
19:39 karolherbst: well
19:39 karolherbst: for dual issueing I only ordered instructions around (same count), +6% more perf
19:40 karolherbst: it quite depends on what you do
19:40 karolherbst: and of course 1 expensive instruction is slower than 2 cheap ones
19:40 karolherbst: but because we don't know, less instructions is the best we can do mainly
19:41 imirkin: tobijk: there's a ISCADD which is a shl + add for a constant shift
19:41 imirkin: nouveau doesn't implement it
19:41 imirkin: there's also a "PO" flag on some of the add variants, which add an extra 1. nouveau doesn't make use of that either.
19:43 tobijk: mh iscadd could be benefical
19:43 karolherbst: imirkin: like a + b + 1?
19:50 imirkin: karlmag: yes
19:50 imirkin: karolherbst: --^
19:50 imirkin: sorry karlmag :)
20:09 tobijk: karolherbst: i was more for a n*3 = (n <<1 ) + n
20:09 tobijk: found that damn often in my shader db :>
20:10 karlmag: imirkin: no worries ;-) I'm getting used to that :-)
20:10 karlmag: Makes me pay a bit of attention too.
21:08 pmoreau: wThe throughput of instructions is available in the CUDA programming guide: http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#maximize-instruction-throughput
21:12 tobijk: pmoreau: ah interesting, thanks