05:01imirkin: gnurou: is the vbios supposed to set bit 1 of 0x2240c?
05:03imirkin: gnurou: it seems like at least the vbios in https://bugs.freedesktop.org/show_bug.cgi?id=97620 doesn't do that
05:03imirkin: (which comes from a GF104)
07:10idl0r: imirkin: thanks. i'll try your patch later today i guess
12:48karolherbst: anybody know a good way to discribe "Speedo" best?
12:56mupuf: karolherbst: Individual chip calibration factor?
12:58karolherbst: mupuf: doesn't matter what you say, I know nothing about it at all, so I would just believe you :D
12:58karolherbst: but yeah, it has something to do with the manufacturing process
12:58mupuf: well, you read speedo from the fuses, right?
12:58karolherbst: I think gnurou said something about it months ago
12:58mupuf: then yeah
12:59karolherbst: it used to be a little device, no idea if it's still true
12:59mupuf: it is just like the calibration for the the thermal diode
12:59karolherbst: really no idea, I just say what I read somewhere
12:59mupuf: speedo is a linear factor for computing the voltage, right?
12:59karolherbst: well somewhat
13:00karolherbst: it is more complicated than this
13:00karolherbst: let us say, it affects the calcuation
13:00mupuf: can you send me a link to it again?
13:00karolherbst: mupuf: https://github.com/karolherbst/nouveau/blob/master_4.7/drm/nouveau/nvkm/subdev/volt/base.c#L118-L131
13:01mupuf: ok, it is a linear factor for multiple parts of the equation
13:01mupuf: whatever, same shit
13:01karolherbst: I see
13:01mupuf: oh, there is a speed squared at some point
13:01karolherbst: and sometimes even multiplied with temperature
13:02karolherbst: see 0x1
13:02mupuf: but yeah, this is basically the individual chip's calibration
13:02mupuf: it may not be calibrated per chip and may be done per batch, but I doubt it
13:03karolherbst: we never will know
13:03mupuf: for all intent and purposes, we should consider it per-chip
13:03karolherbst: but it is pretty precise
13:03karolherbst: value range is somewhat like 0x450 to 0x800
13:03mupuf: basically, there are good chips and bad ones ;)
13:03mupuf: bad ones require a higher voltage
13:03karolherbst: *really good and *really bad ;)
13:03mupuf: good ones require a lower voltage
13:03mupuf: that's it
13:04mupuf: the speedo must be computed based on the transition time of a bunch of test transistors throughout the chip
13:04karolherbst: most likely, yes
13:04mupuf: and they find the worst one and use it for calibration
13:04mupuf: I don't think it is fancier than this
13:06mupuf: still is pretty fancy though :p
13:06karolherbst: well, it was fun to RE at least :D
13:06karolherbst: especially finding that damn register
13:06mupuf: you deserve major kuddos for this1
13:07mupuf: you will get a beer from me at XDC ;)
13:07karolherbst: all I wanted was a stable driver :(
13:07mupuf: Samuel will also get one :D
13:10hakzsam: mupuf, hehe :)
13:16karolherbst: what a silly name "speedo" is
13:17mupuf: well, speed_factor would be better
13:17mupuf: that would be accurate
13:50karolherbst: yeah maybe, I just used the same word like done within the tegra sources
16:41orbea: Anyone mind checking if this apitrace could be an issue (PCSX2 regression) in nouveau only? My thinkpad only blackscreens... http://ks392457.kimsufi.com/orbea/stuff/trace/PCSX2-TOL.trace.xz
16:41orbea: should have missing text and strange shadows
16:43karolherbst: with intel it is black :(
16:43orbea: so I guess its not only my intel...
16:43karolherbst: checking nvidia
16:44karolherbst: mhhh troublesome
16:45karolherbst: doesn't work with nvidia either
16:45orbea: maybe there is something with the apitrace...
16:45karolherbst: llvmpipe also black
16:45karolherbst: "247766: warning: 0:4(12): error: extension `GL_ARB_shader_image_load_store' unsupported in fragment shader"
16:45orbea: replays fine on my desktop at least
16:47karolherbst: orbea: can you make a trace with MESA_EXTENSION_OVERRIDE=-GL_ARB_shader_image_load_store ?
16:47orbea: sure, hold on
16:56orbea: karolherbst: http://ks392457.kimsufi.com/orbea/stuff/trace/PCSX2_TOL_GL_ARB_shader_image_load_store.trace.xz
16:57karolherbst: orbea: did you see that one issue is gone?
16:58orbea: which one? seems the same here, messed up menu, missing text and shadows that hsould not be there?
16:58karolherbst: mhh menu is fine now
16:58karolherbst: nice, llvmpipe works now
16:58karolherbst: "11823: message: major api error 1: GL_INVALID_OPERATION in glTextureBarrier(not supported)"
16:59karolherbst: same shadow issue
16:59orbea: strange. looks like this here http://ks392457.kimsufi.com/orbea/stuff/pics/scrots/pcsx2/2016-09-19-090359_1680x1050_scrot.png
16:59karolherbst: this is with the first trace
16:59karolherbst: but not with the second
16:59orbea: actually no, I was wrong, menu is better
16:59orbea: still missing the text in the though
16:59karolherbst: hakzsam: did you implement GL_ARB_shader_image_load_store?
17:00karolherbst: might be application bug though
17:00orbea: yea, I think it is, but I was thinking maybe its also connected to nouveau since the gsdx dumps the pcsx2 debugger made did not show an issue for Gregory
17:00karolherbst: I see
17:01imirkin_: careful with retrace - you need one with fixed glCopyImageSubData
17:01karolherbst: well it still won't replay for nvidia
17:01karolherbst: imirkin_: what do you mean?
17:01imirkin_: see issue 404 in apitrace github
17:01imirkin_: i think latest release might already have the (fake) fix
17:02imirkin_: anyways, with i965/SKL i saw a weird triangle issue in the menu at the end with the original trace
17:02hakzsam: karolherbst, for sure yes :)
17:02karolherbst: I have 7.1 installed
17:02hakzsam: this is required for GL 4.2 :)
17:02karolherbst: hakzsam: k, there might be an issue somewhere
17:02orbea: apitrace-7.1-x86_64-2_SBo here
17:02hakzsam: but I didn't implement core mesa though
17:02karolherbst: imirkin_: right, me too
17:02karolherbst: imirkin_: but not with the second trace
17:03karolherbst: the shadow seems odd though
17:04karolherbst: more like a real emulation bug+
17:04orbea: im trying to bisect it now, shouldn't take that long actually...
17:04karolherbst: orbea: GL_ARB_shader_image_load_store support maybe?
17:04karolherbst: I would say git bisect is pretty useless except you find a version with enable GL_ARB_shader_image_load_store and without that issue
17:05orbea: it as a recent regression
17:05orbea: I have a build and git commits where it worked
17:05karolherbst: if you mean with recent 2 weeks, that maybe
17:05orbea: 1 week even, thought it would of been like 20 steps, but its only 4
17:05karolherbst: orbea: ahh nice, check for GL_ARB_shader_image_load_store there
17:05karolherbst: ohh okay
17:05karolherbst: yeah, then it should be there for sure
17:06karolherbst: orbea: 20 steps is _a_lot_
17:06karolherbst: 1millions commits
17:06karolherbst: within linux you get usually 14 at most
17:06orbea: that is good to know :)
17:07karolherbst: orbea: what is odd about the shadows though?
17:07orbea: they shouldn't occur at all
17:08karolherbst: I see
17:08karolherbst: still looks like emulation bug
17:08karolherbst: or weird game engine + driver issue
17:08karolherbst: imirkin_: did you also saw some odd shadows in the scene?
17:09karolherbst: orbea: see, so either a core mesa bug or pscx2 ;)
17:10orbea: I figure if its mesa or nouveau it would of been something Gregory messed up that only occurs on some platforms
17:25orbea: yay, I found the bad commit, hopefully Gregory or the guy that committed it can figure somthing out. Thanks for the time. https://github.com/PCSX2/pcsx2/commit/5420fcaf3ad41ba504e55ca366fc56ce19996e8c
17:27imirkin_: that seems somehow unlikely
17:27orbea: i'll test it manually...
17:27imirkin_: are you sure you finished the bisect?
17:28imirkin_: did it say "first bad commit is X"?
17:28orbea: yea http://dpaste.com/2BF45E4
17:28imirkin_: quite odd.
17:28karolherbst: I guess this enabled some option
17:28orbea: yea, did seem kind of wierd.
17:29karolherbst: orbea: try to play around with those options and see what changes
17:29imirkin_: it seems primarily concerned with options in dialogs
17:29imirkin_: my guess is that you took a wrong turn somewhere
17:30orbea: will see in a few minutes when I test it and the commit before it manually
17:34imirkin_: skeggsb: mlankhorst: airlied: one of you should probably do a xf86-video-nouveau 1.0.13 release to get the new ABI support in place
17:35imirkin_: [or teach me how to do those releases, although i don't know that i have the proper permissions for that]
17:36orbea: yaa, seems I went somewhere wrong...
17:44mlankhorst: imirkin_: there's a script in xorg to do it for you
17:44imirkin_: mlankhorst: where?
17:45mlankhorst: important part is making distcheck works
17:45imirkin_: but i'm probably supposed to sign stuff, and upload tarballs... i doubt i have permissions for the latter. or do i?
17:46mlankhorst: do you have access to the nouveau git? separate from mesa
17:46imirkin_: i'm in the 'nouveau' group
17:48mlankhorst: ok in that case
17:49mlankhorst: clone https://cgit.freedesktop.org/xorg/util/modular/
17:50mlankhorst: release.sh does it for you, needs a path to the checked out git tree iirc
17:50imirkin_: ok awesome
18:26idl0r: imirkin_: confirmed; patch did the trick
18:29imirkin_: feel free to reply with a tested-by
18:30imirkin_: so that people know it's not just me being a jerk
18:36idl0r: imirkin_: hm, how does that work? :P
18:37idl0r: haven't used any patchwork instance yet
18:37imirkin_: reply-to-email? :)
18:37imirkin_: you can't do anything in patchwork
18:38karolherbst: Tom^: there?
18:40karolherbst: Tom^: nvapoke 0x21000 40040001 && nvapoke 0x122634 0 && nvapeek 0x0214a8 && nvapoke 0x122634 0x41 && nvapoke 0x21000 40040000
18:40karolherbst: doesn't matter
18:41Tom^: oh right i cant use blob, all envytools still broken, which i suspect is still that missing resource2 file.
18:42karolherbst: it is a simple kernel paramter though :p
18:42karolherbst: ohh wait
18:42karolherbst: let me check something
18:42karolherbst: meh, no trace from you
18:42karolherbst: I could use another gpu for an example...
18:43karolherbst: Tom^: it is fine
18:43karolherbst: got it
18:43Tom^: so uh no nvapokes?
18:56karolherbst: Tom^: what are high clocks for your? 2150?
18:56Tom^: ive never been above 1097
18:57karolherbst: odd though, your chip quality seems a bit worse then the one I found
18:57Tom^: karolherbst: http://i.imgur.com/NnIqKwA.png
18:57karolherbst: how bad
18:58karolherbst: the pokes/peeks should print something lower than 0x691 then
18:59karolherbst: Tom^: boot with iomem=relaxed
19:00Tom^: one day im so setting kexec up-
19:04Tom^: karolherbst: http://i.imgur.com/zWsYc2a.png
19:05karolherbst: as I thought
19:05karolherbst: the one I got has 1681
19:06karolherbst: that means around 50MHz ;)
19:06karolherbst: also a 780 ti
19:06Tom^: not everything needs to be riced you silly gentoo user.
19:07karolherbst: thats production quality though
19:17karolherbst: well mine is over the moon anyway :p
19:26idl0r: imirkin_: i just replied, i hope that works
19:27imirkin_: idl0r: cool, thanks. you were probably moderated, but it should make its way through eventually
19:28idl0r: imirkin_: ah, ok. i just replied by using the mbox version of the patch
19:28imirkin_: yep, good idea :)
20:24orbea: I think I found the pcsx2 bad commit now, it wasn't so much I made a wrong turn in git bisect. It was more that there was something in the source directory I was testing in that masked it or introduced it when not expected... https://github.com/PCSX2/pcsx2/commit/310f13a2f768a823136fd38d092391693d037a30
20:25karolherbst: orbea: huh
20:46pmoreau: imirkin_: How are GLSL global variables handled in NV50 IR? Cause AFAICT, creating Values require a non-null function?
20:47imirkin_: everything goes into the "MAIN" function
20:48pmoreau: Interesting. And NV50 handles that properly, regarding scopes and so on?
20:49imirkin_: well, everything's always in one function
20:49imirkin_: but in theory function calls are supported
20:49imirkin_: although in practice i dunno that it's been tested in the past few years
20:49pmoreau: Oh right, forgot about that
20:49karolherbst: crappy airline, my light got canceled :/ will arrive later
20:49pmoreau: karolherbst: :-(
20:50karolherbst: "lack of crew", troublesome
20:50karolherbst: I still will arrive at 10pm
20:50karolherbst: so ain't _that_ bad
20:50pmoreau: Still before hakzsam :-)
20:51hakzsam: yup, I will land at 11pm :/
20:51karolherbst: so, the question is, do I need a new board card? :D
20:52karolherbst: ahh I have a new one already
20:52pmoreau: imirkin_: I’ll have to think about it some more. I am unsure how global variables are handled in OpenCL, who is responsible for allocating the global memory.
20:53imirkin_: pmoreau: could still do it in a MAIN function
20:53imirkin_: pmoreau: also are they meant to go into registers or memory?
20:53pmoreau: Well, that will work as long as I only have one kernel.
20:54pmoreau: Which isn’t too far fetched for the time being :-D
20:54imirkin_: pmoreau: have a look at how all the linkage stuff works between functions... you could make them implicit arguemnts to every kernel or something
20:55imirkin_: functions have ins and outs
20:56pmoreau: I’ll talk with Jason and Connor about it, since I am not quite sure what those OpUndef are, and why the compiler would decide to declare it global, when it represents a variable declared within a function body.
20:57pmoreau: Passing a pointer to it as argument seems reasonnable.
21:23karolherbst: mhh I get linking errors in glmark2
21:23imirkin_: yeah, that's expected i think
21:23karolherbst: "Failed to link program created from files None and None: error: declarations for uniform `modelview` have mismatching precision qualifiers"
21:23karolherbst: and then it segfaults later :/
21:23imirkin_: there's a bug about it
21:23karolherbst: ahh I see
21:23karolherbst: nouveau specific?
21:24karolherbst: ahh I think I saw that bug actually
21:32karolherbst: should I be troubled when I hear noises coming from my gpu?