00:54 mangix: alright, MMIO error seems a result of the i2c changes
00:55 mangix: guess that's what IBUS means...
01:22 mwk: mangix: IBUS is the thing that delivers MMIO accesses to their destination, if you get a fault from it, you most likely hit an invalid address
01:22 mwk: that, or the address is valid, but disabled at the moment somehow
01:34 mangix: yeah I bisected the issue
01:35 mangix: aka pulled kernel 4.11's nouveau and cherry picked patches
01:36 mangix: location 022554 has been in nouveau forever, so it can't be that. nevertheless, removing the read does fix the issue with no apparent downside
01:49 mangix_: alright, running airodump-ng on an interface in AP mode crashes ath10k. good to know
02:43 imirkin: karolherbst: see "[RFC v2 0/3] More precise rcp and rsq for fp64 on gk110"
02:43 imirkin: testing it out now
03:02 imirkin: karolherbst: ok, looks like the RA is perfectly bogus: https://hastebin.com/esavedelar.pl
03:20 imirkin: this is a long-standing issue with our RA and pre-existing fixed registers and clobbers
03:50 imirkin: w00t, fixed
03:51 imirkin: mod is still broken though
03:51 imirkin: it's the stupid issue where it's not QUITE equal as a result of inaccuracy, i think
09:00 karolherbst: imirkin: okay now clue, there is no BGR10X or B10G10R10X2 or anything like that, just BGR/RGB10A2 stuff and R11G11B10_FLOAT. But there aren't even G80_SURFACE_FORMAT_ macros for it
09:00 karolherbst: maybe it's simply missing? no idea why it'S getting used then though
10:53 karolherbst: yo, "// R11G11B10_FLOAT TODO"
10:55 karolherbst: but I doubt those assembly things are even used at all
11:33 karolherbst: ohhh
11:34 karolherbst: imirkin: intel has the same error for copy_image
11:37 karolherbst: mupuf: did you work on integrating CTS into ezbench already?
12:19 karolherbst: okay, the conversion is simply wrong
12:21 karolherbst: 0xc7f00004 is a:3 b:7f r:4 and gets converted to b:31f g:600 r:0
12:21 karolherbst: which is 0xc7f00000
12:25 karolherbst: and it should be 0x1fc00000 (b:7f r:4 g:0)?
12:25 karolherbst: don't know much about format conversions and copy_image
12:30 karolherbst: ohh, copy_image doesn't do conversions, right?
12:43 jkucia: karolherbst: right, copy_image is a memcpy()-like thing
12:49 karolherbst: mhh, that CTS test interpet the copied pixels though according to their format
12:50 karolherbst: maybe the test is wrong
12:51 karolherbst: okay, now I get proper data
12:52 karolherbst: 0x39b1e44 vs 0x39b19d4
13:03 karolherbst: okay, now I understand how this test is checking the data
13:42 karolherbst: ohhhh
13:43 karolherbst: at least it works on nvidia
13:43 karolherbst: okay, this test does some texture -> rb -> texture copy
13:43 karolherbst: and checks if nothing vanished
13:48 karolherbst: no way...
13:56 karolherbst: okay, what is wrong here
14:01 karolherbst: texture is internalformat = GL_RGB10_A2, gets copied to RB copied to tex with internalformat = GL_R11F_G11F_B10F
14:07 tobijk: imirkin: karolherbst: the def (%r473) at line 5 should'nt be an immediate?! https://hastebin.com/geravuvole.pl
14:08 karolherbst: tobijk: what do you mean?
14:08 tobijk: the value in %r473 is seen as an immediate, but imho that is a bug
14:09 tobijk: "FILE_IMMEDIATE"
14:09 karolherbst: mhh
14:09 karolherbst: $r1 is an output of call, right?
14:09 tobijk: right
14:10 karolherbst: yeah, then it shouldn't be an immediate
14:33 karolherbst: mhhh
14:34 karolherbst: nvidia returns GL_INVALID_VALUE for those glCopyImageSubData
14:34 imirkin: karolherbst: ARB_copy_image does a bit-for-bit copy, it doesn't care about the formats
14:35 imirkin: (except when it does... very confusing stuff)
14:35 karolherbst: yeah, I already figured that out
14:36 imirkin: i fixed dboyan's fp64 stuff, and also filed that vk-gl-cts bug for mod()
14:36 karolherbst: there was something regarding compression inside the spec
14:36 karolherbst: nice
14:36 karolherbst: do you have it pushed somewhere?
14:37 imirkin: my 'cts' branch
14:38 imirkin: bug at https://github.com/KhronosGroup/VK-GL-CTS/issues/51
14:38 karolherbst: yeah, saw it already, thanks
14:38 karolherbst: this copy_image thing is annoying... there _is_ something at the red channel, at least according to apitrace
14:39 karolherbst: but it's more like 0.00000something where the other values are like super high
14:39 karolherbst: and nvidia just fails on those calls
14:40 imirkin: if it happens with other drivers, get help from other people
14:40 karolherbst: but only for the 7x7 copies
14:45 karolherbst: imirkin: will write an email if nobody answers on IRC later. anyhow, I kind of understood how the tests does stuff: 1. copy from GL_RGB10_A2 texture into RB copy from RB into GL_R11F_G11F_B10F texture. Would you say this is a valid request on nvidia GPUs?
14:46 imirkin: what format is RB?
14:46 karolherbst: checking
14:47 karolherbst: GL_RGB10_A2
14:47 imirkin: and what fails?
14:47 imirkin: [on nvidia]
14:48 karolherbst: both glCopySubData calls for copies of size 7x7, there are a bunch of 1x1 which are fine
14:48 karolherbst: but maybe the RB is different on those prior tests
14:48 imirkin: dunno, seems like it should work.
14:49 imirkin: there are a number of reasons it can fail
14:49 imirkin: like if it's out of bounds
14:49 imirkin: or the formats aren't in the same format group
14:49 karolherbst: "10468: message: major api error 1281: GL_INVALID_VALUE error generated. <srcName> or <dstName> does not correspond to a valid texture object."
14:49 imirkin: sounds like a bug inside nvidia wrt allocating a backing buffer for the RB
14:49 karolherbst: mhh, there is something interesting
14:50 karolherbst: "Framebuffer detailed info: The driver allocated storage for renderbuffer 1" and the first tests use renderbuffer 1
14:50 karolherbst: but the failing one, uses 2
14:50 imirkin: but ... who knows.
14:50 karolherbst: and there is no such message
14:51 karolherbst: but the test passes on nvidia, which is odd
14:54 imirkin: ooooh.... i wonder if we can start returning INVALID_VALUE for that super-duper-annoying rgba4 case
14:55 imirkin: it *is* passing in GL_RENDERBUFFER for the rb i assume...
14:56 imirkin: (hrm, no. the exception is for internalformat == base internal format... not for when-you-feel-like-it)
15:04 karolherbst: imirkin: what do you mean by that? "dstTarget = GL_RENDERBUFFER" or do you mean something else?
15:05 imirkin: nope, that's what i mean
15:05 imirkin: and dstName = 2 or whatever?
15:05 karolherbst: glCopyImageSubData(srcName = 4, srcTarget = GL_TEXTURE_2D, srcLevel = 0, srcX = 0, srcY = 0, srcZ = 0, dstName = 2, dstTarget = GL_RENDERBUFFER, dstLevel = 0, dstX = 0, dstY = 0, dstZ = 0, srcWidth = 7, srcHeight = 7, srcDepth = 1)
15:06 imirkin: yea dunno
15:06 karolherbst: and the second copy: glCopyImageSubData(srcName = 2, srcTarget = GL_RENDERBUFFER, srcLevel = 0, srcX = 0, srcY = 0, srcZ = 0, dstName = 3, dstTarget = GL_TEXTURE_2D_ARRAY, dstLevel = 0, dstX = 0, dstY = 0, dstZ = 0, srcWidth = 7, srcHeight = 7, srcDepth = 1)
15:06 karolherbst: it also kind of works
15:06 karolherbst: pixel at 0,0,0 has the value 0xc7f00000 and it ends up being 0xc7f00000
15:07 karolherbst: just 1,0,0 is 0xc7f00004 and it ends up being 0xc7f00000
15:07 karolherbst: mhhhh
15:07 karolherbst: maybe 0,0,0 is copied into the entire 7x7 rectangle?
15:07 karolherbst: checking the other values
15:08 karolherbst: yeah, everything is simply 0xc7f00000
15:27 tobijk: hmm, since when do we crash in these shaders? https://hastebin.com/acizofaxig.http
15:29 karolherbst: tobijk: bisect please :p
15:30 tobijk: karolherbst: yeah i'm finishing the patch for the CALL thingy first (final shader_db runs)
15:31 tobijk: meh which does not work because of the crashes ~_~
16:02 imirkin: tobijk: what CALL thing?
16:08 tobijk: the propagate immediates to the movs for CALLs
16:08 tobijk: imirkin: https://hastebin.com/ojodahomun.php
16:09 imirkin: oh
16:10 imirkin: hm. right. annoying.
16:10 imirkin: the issue is, further, that you end up with a potentially unused op which you should remove in such a case.
16:10 tobijk: imirkin: yeah it is eliminated later on
16:10 imirkin: by what?
16:10 tobijk: not sure if i really should handle it here
16:11 imirkin: no CSE is run at the legalize stage...
16:11 tobijk: imirkin: dunno, it is eliminated though :D
16:11 imirkin: perhaps RA ends up nuking it.
16:11 imirkin: but ... that'd be odd
16:11 imirkin: please do the delete_Instruction right there
16:11 tobijk: k
16:14 imirkin: [but only if it no longer has any uses]
16:15 tobijk: imirkin: yep, of course
16:18 tobijk: karolherbst: bisecting is a real pain for that problem, we had so many build errors lately ~_~
16:18 tobijk: we as in mesa
16:49 tobijk: mh karolherbst, i have bisected, now fix your mess ;-) : https://cgit.freedesktop.org/mesa/mesa/commit/?id=24a799ad35a824fba94062f9b018f603717ed145
16:50 imirkin: that might be my bad - i changed his patch
16:50 imirkin: what's the issue?
16:50 tobijk: or does it work for you on pre gm107?
16:50 tobijk: run: codegen/nv50_ir_emit_gm107.cpp:344: void nv50_ir::CodeEmitterGM107::emitIMMD(int, int, const nv50_ir::ValueRef&): Assertion `!(val & 0x00000fff)' failed.
16:50 tobijk: => CRASHED <= while processing these shaders:
16:50 tobijk: imirkin: --^
16:51 imirkin: backtrace
16:51 imirkin: and the tgsi shader, if possible
16:51 tobijk: havent captured one yet, sec
16:51 tobijk: have to run right now, will be back soon
16:51 imirkin: ok
16:52 imirkin: i'm updating the nvidia_shaderdb right now...
17:17 tobijk: ok, that got a long sec :D
17:17 tobijk: imirkin: crashing shaders: https://hastebin.com/tacemisace.go
17:18 imirkin: tobijk: well, if you could get me the TGSI that'd save me a step
17:27 tobijk: imirkin, this one should be it: https://hastebin.com/uxemebibam.php
17:29 imirkin: nouveau_compiler: codegen/nv50_ir_emit_gk110.cpp:414: void nv50_ir::CodeEmitterGK110::emitForm_C(const nv50_ir::Instruction*, uint32_t, uint8_t): Assertion `0' failed.
17:29 imirkin: yay
17:30 imirkin: oh. fun!
17:31 imirkin: something's trying to saturate 0.99989998 and it can't coz of the immediate arg.
17:31 imirkin: how that makes it through the constfolding is a mystery
17:31 imirkin: but i'll work it out.
17:33 imirkin: 217: sat ftz f32 %r4247 0.999900 (0)
17:33 imirkin: well it's definitely there :)
17:34 tobijk: :)
17:34 tobijk: imirkin: btw didn you update the shaderdb yet?
17:35 imirkin: i'd have to remember how to run it
17:35 tobijk: uhm, just thought you would push some more shaders, never mind
17:42 imirkin: i think i figured it out. fix coming up
17:45 imirkin: patch on list.
17:45 imirkin: https://patchwork.freedesktop.org/patch/171599/
17:45 imirkin: tobijk: karolherbst --^
17:46 tobijk: yep
17:46 karolherbst: uhh
17:48 tobijk: imirkin: tested and reviewed
17:48 tobijk: works :)
17:49 imirkin: karolherbst: can you test the game that was originally broken that you fixed, just to double-check?
17:50 karolherbst: imirkin: yeah
17:51 imirkin: wonder if i should go one step further and do like if (src.getImmediate())
17:51 imirkin: probably should
17:55 imirkin: v2: https://patchwork.freedesktop.org/patch/171600/
17:58 tobijk: imirkin: hmm shouldn getImmediate() return one if it really exists? it confuses me: Immediate %473: mov u32 %r473 $r1 (0)
17:58 imirkin: not sure i understand the question.
17:59 imirkin: getImmediate should return 1 if it's an immediate, yes.
17:59 imirkin: $r1 is never an immediate though... it's a fixed register.
18:00 tobijk: yeah, if i do: ld->src(0).get(); and check for an immediate with reg.file != FILE_IMMEDIATE it is no immediate, if i check with ld->src(0).getImmediate(imm), it is one
18:00 tobijk: that confuses me, yet i know it shouldnt be one
18:01 tobijk: does it make one up in that case? :O
18:03 tobijk: imirkin: https://hastebin.com/hijezodenu.php
18:04 imirkin: it finds the ultimate immediate
18:04 tobijk: ups make the last != to ==
18:04 imirkin: so like if you have
18:04 imirkin: mov a, b
18:04 imirkin: mov c, a
18:04 imirkin: mov d, c
18:04 imirkin: and b happens to be an immediate
18:04 imirkin: and the last mov == ld
18:05 imirkin: ld->src(0).getImmediate() will get you b
18:05 imirkin: when in doubt, RTFS
18:05 imirkin: [to see what getImmediate does]
18:05 tobijk: yet it gets me a: mov u32 %r473 $r1 (0)
18:05 tobijk: as insn, heh
18:06 imirkin: and immediate is an immediate... it's not an instruction
18:06 imirkin: it's just a Value
18:06 imirkin: if (ld->src(0).getImmediate(imm) && imm.reg.file == FILE_IMMEDIATE) {
18:07 imirkin: don't need to do that.
18:07 imirkin: ld->src(0).getImmediate(imm)
18:07 imirkin: if that returns true, then imm is filled in with good stuff.
18:07 tobijk: nope it isnt, thats my problem
18:07 tobijk: it points to the %r1 above
18:07 imirkin: that means shit's messed up.
18:07 imirkin: %r1 or $r1?
18:07 imirkin: either way, both are impossible
18:07 tobijk: $r1, sry
18:07 imirkin: since both of those are FILE_GPR
18:10 tobijk: well you are right, the second one in the code snippet works (and sees the same value as we collapsed the chain already),yet getImmediate does not
18:10 imirkin: "you are doing something wrong"
18:11 karolherbst: imirkin: I guess we should have a CI run compiling all the shaders we have so that we notice regressions like that faster, added to my CI todo list
18:14 karolherbst: imirkin: patch looks fine, no visual regressions as far as I can tell with that game
18:14 imirkin: ok cool
18:15 tobijk: imirkin: , so why is%473 an immediate here with getImmediate() (i havent touched that insn, btw): https://hastebin.com/isevopavos.pl
18:15 tobijk: just wondering :o
18:16 imirkin: perplexing. one would have to step through the code to figure out wtf is going on.
18:16 karolherbst: I would assume the call handling is a bit broken maybe
18:16 imirkin: tobijk: oh, but note that i have a small change
18:16 imirkin: in my cts branch, which could fix the issue
18:17 imirkin: tobijk: https://github.com/imirkin/mesa/commit/44c0c144c69117ec80f280df95906360dd9239bd
18:18 imirkin: but it _really_ shouldn't matter.
18:18 imirkin: so i'd be surprised if it helped
18:19 tobijk: imirkin: then you have something to think about as well
18:19 tobijk: - bld.mkMov(i->getDef(0), def[(i->op == OP_DIV) ? 0 : 1]);
18:19 tobijk: + bld.mkMovFromReg(i->getDef(0), i->op == OP_DIV ? 0 : 1);
18:19 tobijk: does the trick
18:20 tobijk: the bad imm is gone
18:22 imirkin: that's ... very surprising.
18:31 imirkin: tobijk: oh, i get it.
18:31 imirkin: heh
18:31 imirkin: it went up the value chain, and since the src was linked to the def, it thought nothing of just making that jump
18:32 imirkin: which is ... normally fine. just not for "real" registers.
18:44 imirkin: tobijk: i'll push it out now that i have an reasonable explanation to why it helps :)
18:54 tobijk: imirkin: all right, thanks
18:55 tobijk: makes my patch easier :D
19:04 tobijk: imirkin: for some yet unknown reason your patch regressed my test shader for some bytes :O
19:05 tobijk: anyway hoepfully mine will fix that again
19:35 tobijk: imirkin: ok follow up patch for the CALL is on the ML
20:07 imirkin: tobijk: it might end up impacting how RA is done but ... for the better
20:07 imirkin: by better i mean "more correct" :)
20:08 tobijk: imirkin: yeah the regression is minor (and with my patch there is potentially a positive outcome)