01:37 dboyan_: Echelon9: got it. thanks!
02:12 imirkin: dboyan_: https://people.freedesktop.org/~airlied/piglit/cts-nouveau-open/cts1/gl45-cts@gpu_shader_fp64@built_in_functions.html
02:12 imirkin: does this test pass now? i assume not due to sqrt() but worth checking...
02:12 imirkin: [still need to look at your v2]
02:44 dboyan_: imirkin: The laptop is not at my side for now
02:45 dboyan_: How do I run the test btw? Just clone the VK-GL-CTS and somehow run with piglit?
02:50 imirkin: dboyan_: well, you can use the command that's in that html file
02:50 imirkin: might want to replace "airlied" with "dboyan".
02:50 dboyan_: ah i see
02:51 imirkin: bbl... maybe.
04:59 Horizon_Brave: Anyone watch the Expanse?
09:16 karolherbst: imirkin_: got a replay. They indeed decide on a different buffer upload path depending on the driver, but they said that they always check for feature availability (tm), I guess I will take a deeper look why we fail when forving the nvidia vendor then.
09:17 karolherbst: *forcing
10:15 karolherbst: wow, those feral guys are indeed super helpful, I like that :)
10:21 hakzsam: karolherbst: do you have access to the NVIDIA blob right now?
10:21 hakzsam: if so, could run one test for me?
10:21 hakzsam: +you
10:22 karolherbst: I am at work
10:22 hakzsam: ok, np
10:23 karolherbst: feral will make hitman use the same preferences than radeonsi for now, which fixes those visual corruptions, but trigger bugs inside our driver :D but I am sure we will be able to fix those
10:24 pmoreau: That’s great!
10:28 karolherbst: hakzsam: but for stuff like that, you can ask me around 9-12 pm until the 24th. After that I will have more time again :(
10:30 hakzsam: ok, thanks
11:08 karolherbst: uhh, mhhh. hakzsam, imirkin_ : did you sign any NDA for feral for getting more information?
13:46 dboyan: imirkin_: Can't we just merge the neg3b into the FIMM or DIMM just like I3BIMM? so that things like f32 neg 0x3f800000 will become 0xbf800000
13:48 dboyan: the sign bit of f16 is just bit 15, and that reminds me that neg3b is nothing other than bit 19 of immed value
13:49 dboyan: and it can eliminate the double neg madness discussed yesterday
14:13 imirkin_: karolherbst: nope, but i also never got any info from them, so it works out :)
14:13 imirkin_: dboyan: if you can, that's fine with me... not sure how that works tbh
14:14 dboyan: imirkin_: I'm working on a new branch, will finish them in minutes
14:28 dboyan: imirkin_: https://github.com/dboyan/envytools/tree/cvt-immed-2
14:35 imirkin_: dboyan: long immediate = 32-bit
14:35 imirkin_: dboyan: i.e. LIMM
14:36 imirkin_: dboyan: i bet that most of those have legit neg flags... check neg30 on those :)
14:39 dboyan: imirkin_: Is there what I'm missing?
14:39 imirkin_: well, i bet there's a T(neg30) on e.g. the set
14:40 dboyan: for the limm?
14:40 imirkin_: no, the FIMM
14:40 imirkin_: the limm reference is to
14:40 imirkin_: +F1(neg3b, 0x3b, N("neg")) // add,fma long immediate src1
14:40 imirkin_: 
14:47 dboyan: imirkin_, I finally got what you were saying
14:48 dboyan: but no, there is not T(neg30) in the set instruction
14:48 imirkin_: ok. you checked? :)
14:48 dboyan: yeah
14:48 imirkin_: cool
14:48 imirkin_: 0xffc - that's wrong
14:49 imirkin_: should be 0xf7c
14:49 dboyan: oh! I forgot that
14:49 imirkin_: (what idiot laid out the bits of this isa...)
14:51 dboyan: one of the problem is about f16, which is set to I3BIMM. A careless user will make invalid input there
14:52 dboyan: I once wanted to add an HFIMM type, but there are also 8/16 bit integer immeds
14:52 imirkin_: i don't care about careless users.
14:52 dboyan: I tend to agree
14:52 imirkin_: the only users are people in this chan
14:56 dboyan: imirkin_: I pushed a new commit to that branch, the 0xffc's were fixed
14:56 imirkin_: ok cool
14:56 imirkin_: i don't really have time to look now
14:56 imirkin_: but i unboxed my desktop last night... still haven't plugged it in, but making progress
14:56 imirkin_: [i want to clean it up first, and reconfigure my gpu situation]
14:57 imirkin_: i'm thinking NV34, NV44, GF108, and GK208. maybe GM107 instead of the GK208. tbd.
14:57 karolherbst: imirkin_: well they asked me to sign one. Well if they give me a lot of information, that's fine, but then I would need to learn more about nvc0 in mesa :D
14:58 dboyan: imirkin_, I'll submit a PR, you can review and merge it when you have time.
14:58 imirkin_: dboyan: ok
15:00 imirkin_: i think you can force-push the branch and that updates the github pull request...
15:02 dboyan: umm, never force pushed before, will practice that next time :)
16:31 tarragon: what are the first tools that i need to install in order to help development here?
16:31 tarragon: after the conversation with karol yesterday I want to give it a try.
16:34 imirkin_: what kind of help were you looking to provide?
16:41 tarragon: mesa's on-disk shader/textures cache and opencl
16:41 tarragon: imirkin_: according to karol the first got the code already put in place so I am suspecting is a matter of porting only.
16:43 imirkin_: what's this texture cache that you keep talking about?
16:43 imirkin_: the only way i can think of it is that it'd slow things down
16:44 tarragon: imirkin_: on the contrary, it offers amazing boost!!
16:44 imirkin_: how
16:44 imirkin_: how can the GL do any kind of caching on that which would in any way be beneficial
16:45 imirkin_: for the *application* it might make sense to cache various computation results, but i don't see how the GL can do anything useful.
16:45 imirkin_: but ... always happy to be enlightened
16:45 tarragon: https://www.phoronix.com/scan.php?page=news_item&px=Mesa-Cache-Multi-Archs
16:46 imirkin_: i certainly don't plan to read anything on that site, the guy who writes it is largely after page views, not accuracy.
16:46 imirkin_: if there's a real article that he's using as a source, sure.
16:47 imirkin_: (and i'm guessing it's about shader cache, not any sort of texture cache)
16:47 tarragon: the article got a link on the commit but not much of an explanation --> https://cgit.freedesktop.org/mesa/mesa/commit/?id=e3a01a5d1b019e7b00218ba526874f4c77ea8bee&utm_source=anzwix
16:47 imirkin_: right, which is the shader cache.
16:47 imirkin_: still don't see how a texture cache can help.
16:48 tarragon: imirkin_: does this work with nouveau?
16:48 imirkin_: it's not hooked up, but should be trivial to do
16:50 tarragon: imirkin_: so basically look how is hooked up with radeon and apply the code to nouveau?
16:50 imirkin_: something like that yeah
17:14 tarragon: I wonder when sweatheart karol joins.
17:18 pmoreau: Echelon9: I’ll have a look at some of your MRs during the week-end, or maybe even tonight.
17:19 pmoreau: I still get warnings for the pylint one, but they can be fixed in another MR. We should probably set up some automatic pylint test, or at least have a .pylintrc inside the repo.
17:31 Echelon9: pmoreau: Yes, I didn't attempt to fix all the pylint warnings yet
17:32 Echelon9: Wanted to get the easier fixes landed, to not be held up by those fixes which are more subjective / design-based and require a separate discussion
17:33 pmoreau: Makes sense
17:33 Echelon9: Adding pylint to the testing is my objective, so then we get that for free as part of the Travis-CI testing
17:33 pmoreau: Ah, that would be good! I was wondering if it could be part of the Travis-CI testing.
17:33 Echelon9: I've also been working on essentially xmllint to go through rnndb
17:34 pmoreau: Nice! :-)
17:34 Echelon9: Similar to pylint, there's some easy wins -- then some that require subjective / design-based discussion
17:34 Echelon9: Getting xmllint or similar in the Travis-CI testing would be neat too
17:34 pmoreau: Yup, definitely
17:35 Echelon9: If you're interested in the work in progress RFC: https://github.com/envytools/envytools/compare/master...Echelon9:feature/rnndb-validation
17:36 pmoreau: Thanks, I’ll have a look
17:38 pmoreau: For https://github.com/envytools/envytools/pull/68/files, I was wondering about putting a link to index.rst inside envydis/envyas.c, on top of (or instead of) the documentation you added, as that documentation does not include which ISAs are valid.
17:41 pmoreau: Btw, GitHub seems to be messing up the rendering of docs/envydis/index.rst, or there is something weird with the rST.
17:43 pmoreau: I need to finish some stuff first, but I’ll have a look at it later today.
17:48 Echelon9: I think there might be some non-standard rST in docs/envydis/index.rst
17:48 Echelon9: I threw the raw text at two random web rST validators / editors that appears on page 1 of Google, both reported errors with the blocks that GitHub doesn't render
17:49 Echelon9: e.g. System Message: ERROR/3 (<string>, line 17) Unknown directive type "option".
17:55 pmoreau: Ok
19:14 mwk: Echelon9: it's not plain rst, it's sphinx
19:14 mwk: and it's auto-built at http://envytools.readthedocs.io/en/latest/
19:14 mwk: it won't work without sphinx-specific directive support
19:15 mwk: + some of the files already use an envytools-specific extension to sphinx
19:15 mwk: pretty much the only way to build it is to use the makefile in docs/
19:15 Echelon9: mwk: As expected. Thanks, that makes sense that there's some extensions
20:48 mooch2: mwk: the nvidia drivers on windows do state checks once put into an NV-specific mode :/
20:51 mwk: state checks?
20:55 mooch2: yeah, like the ones your hwtests do
20:56 mooch2: it only seems to be checking the 2d regs so far
20:56 mooch2: in pgraph
20:59 mwk: oh, you mean reading back the PGRAPH regs?
20:59 mwk: that's quite expected, it has to load/unload channels
21:00 mooch2: yeah but it's not writing anything back to them
21:01 mwk: huh.
21:02 mooch2: it just has a black screen after reading the pgraph regs a bunch of times, and also turning on interrupts
21:02 mooch2: no pfifo method submissions
21:03 mooch2: i take that back, it DOES write 0 to a bunch of pgraph regs
21:05 mwk: that'd be the initial context load, probably
21:28 mooch2: then why does it never get past that?
21:56 karolherbst: imirkin_: :)
21:56 karolherbst: imirkin_: you should also get the reply, didn't you?
21:57 imirkin_: i did.
21:59 karolherbst: do you have a little time to debug hitman a bit further? By any chance, do you know how I am able to set memory watchpoints in gdb manually on a certain trigger and remove them again?
21:59 imirkin_: not right now.
21:59 imirkin_: but i'll be able to set up my desktop tonight. for real. so probably later :)
22:00 karolherbst: well, I will go to be in an hour or so... because of silly reasons ;)
22:00 imirkin_: like it's late? :)
22:00 karolherbst: no, have to work tomorrow
22:00 imirkin_: ah right
22:03 karolherbst: mhhh, maybe enabling reverse debugging won't slow down things that much... but I doubt it works with multiply threads, never used it in gdb at all
22:04 imirkin_: if it's always the same tx
22:04 imirkin_: you can set a watchpoint on tx->mm
22:04 imirkin_: and see when it gets overwritten
22:04 imirkin_: er, tx->map
22:04 karolherbst: what do you mean it is always the same tx?
22:04 imirkin_: like
22:04 imirkin_: if it's always after the 4th transfer
22:04 imirkin_: you can use breakpoints to get to the 4th transfer
22:04 imirkin_: and then at that point, set a watchpoint on the tx->mm that always gets corrupted
22:05 karolherbst: uhm... you are aware I cut off like a lot?
22:05 karolherbst: and that this happens in the 2000th frame?
22:05 karolherbst: or so
22:06 karolherbst: or what did you mean by 4th?
22:07 imirkin_: then that sucks :)
22:07 karolherbst: :D yes
22:08 karolherbst: I could add a watchpoint to every tx on allocation and clear it at deallocation again
22:09 karolherbst: ohh
22:09 karolherbst: I bet I can add some gdb function calls to the code or so
22:14 john_cephalopoda: Hey.
22:14 john_cephalopoda: I got some weird issue...
22:16 john_cephalopoda: I'm not 100% sure it is related to nouveau, but it could well be.
22:16 john_cephalopoda: https://lut.im/eAdNRTZJhU/8R3n4aYfLU4213X9.png
22:16 karolherbst: imirkin_: do you know by any chance, how I can add a watchpoint for tx->map by taking it's address?
22:16 imirkin_: john_cephalopoda: let me guess... you're using xf86-video-modesetting + glamor?
22:16 karolherbst: not the expression
22:16 imirkin_: karolherbst: sorry, my gdb-fu is weak in those areas. i just search around :)
22:17 karolherbst: I am trying already
22:18 karolherbst: imirkin_: show can-use-hw-watchpoints
22:18 karolherbst: ...
22:18 karolherbst: watch -location tx->map
22:20 john_cephalopoda: imirkin_: It tells me that I only have nouveau from xf-86-video
22:20 imirkin_: is this X or Wayland or XWayland?
22:22 john_cephalopoda: imirkin_: This is X, to be exact 1.19.2 xorg-server
22:22 imirkin_: pastebin xorg log for me
22:22 john_cephalopoda: Uhrg, it's hard to write like this, without seeing what I iwrite.
22:23 john_cephalopoda: Which one? There are XOrg0/1.log(.old)
22:23 imirkin_: from your currently-running X server that's having the issues in question
22:24 john_cephalopoda: Hmm, could it be that my dbus died?
22:27 john_cephalopoda: https://bpaste.net/show/fe51c7550d7b
22:27 john_cephalopoda: Wait, that is an old log
22:27 john_cephalopoda: Or is it?
22:27 imirkin_: [ 19.461] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Mar 10 22:58:22 2017
22:27 imirkin_: not that old...
22:27 imirkin_: ok, you are indeed using xf86-video-nouveau.
22:27 john_cephalopoda: Ah, was confused because of "Release Date: 2017-03-02"
22:28 karolherbst: meh... I hace only 5 hw watchpoints :/ annoying
22:28 john_cephalopoda: Hmm... I'll reboot and see if the bug persists.
22:28 imirkin_: john_cephalopoda: do you see errors in dmesg?
22:28 imirkin_: feels like a font texture got messed up somewhere
22:29 imirkin_: i'm sure restarting X will fix it
22:29 john_cephalopoda: brb
22:30 john_cephalopoda: Yep, works now.
22:30 imirkin_: you may be aware, but you can now manually reclock your gpu (with kernel 4.10 which you seem to be using)
22:31 john_cephalopoda: What's the advantage of that?
22:31 imirkin_: maor fps
22:31 imirkin_: the default clocks on keplers are laughably low
22:32 imirkin_: like 100mhz or so... depends on the board
22:32 john_cephalopoda: I'll have to look up how to reclock it.
22:34 imirkin_: just echo stuff to /sys/kernel/debug/dri/0/pstate
22:36 john_cephalopoda: Now I have to find the kernel option that enables this.
22:36 imirkin_: should be on by default
22:36 imirkin_: unless you don't have debugfs
22:37 imirkin_: [obv have to be root, since debugfs is root-only]
22:42 john_cephalopoda: Hmm, /sys/kernel/debug appears to be empty.
22:43 john_cephalopoda: Maybe not mounted.
22:48 john_cephalopoda: Okay, mounted.
22:48 john_cephalopoda: So I just echo "0A" > pstate ?
22:48 imirkin_: 0a, but yeah
22:49 imirkin_: (maybe 0A works? dunno)
23:00 john_cephalopoda: Woah. That's a speedup. From 496.918 FPS via 1394.337 to 2912.990 FPS.
23:01 john_cephalopoda: Very nice.
23:13 john_cephalopoda: Thanks for all the hard work on the driver!
23:13 imirkin_: [note that glxgears is not a benchmark of 3d performance]
23:15 karolherbst: imirkin_: well, fermi GPUs are worse. Kepler is usually fine with boot clocks. Mine boots at 405MHz for example
23:15 karolherbst: and 135MHz is the lowest I saw
23:16 john_cephalopoda: My GPU boots with 648 MHz and supports up to 4000 MHz.
23:16 karolherbst: this is memory
23:17 karolherbst: we meant core
23:17 john_cephalopoda: 648 being the lowest supported on my GPU.