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