08:23 thican: Hello everyone! I am reading on this webpage that the support for GP107 GPU is available in kernel 4.12 http://www.phoronix.com/scan.php?page=news_item&px=GP10B-GP107-DRM-Next
08:24 thican: But unfortunately, I can't get it working
08:24 thican: In fact, it looks like I have an old version of linux-firmware, from 2017-03-14
08:25 thican: do you think this is new enough?
08:27 pmoreau: thican: Not new enough, the fixed firmwares were committed on 31 March :-) https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/nvidia/gp107?id=7c7785c3fca909d876e506e337eaa771a8f4dcbc
08:27 thican: ah, this is whatI tought, thanks for your answer, pmoreau :-)
12:37 bloblo: Helloo
12:37 bloblo: i have gtx 770
12:38 bloblo: is working beautifully (i am on 4.13-rc4 kernel), i overclock with bios flash
12:40 bloblo: frequence show correct, with sensors powerlimit W also is correct, but voltage is showing stock voltage 1.21 but i set more 1.21, is normal or i something wrong in my overvolt ?
12:41 bloblo: i need change something value in kernel (if is fixed value) ?
12:42 bloblo: after i reback for view if any reply ++ thanks advance
13:34 rhyskidd_: thican: If you're using that GP107 in a hybrid iGPU/dGPU arrangement (i.e. laptop) expect issues still unfortunately
13:35 rhyskidd_: Still working through some bugs https://bugs.freedesktop.org/show_bug.cgi?id=100228
13:42 thican: rhyskidd_: I have a "normal" graphic card device for a desktop computer :-)
13:43 rhyskidd_: Lucky you :)
13:43 thican: it's not luck if it's on purpose ;-)
13:43 rhyskidd_: Let us know if you have any other issues with that card on nouveau
13:46 thican: rhyskidd_: for now on, it looks like okay, but I notice I don't have the same interface with my DE (Desktop environment) than with Nvidia drivers
13:57 rhyskidd_: ccaione: Was the mmiotrace you supplied at https://bugs.freedesktop.org/show_bug.cgi?id=101601 done on nvidia blob driver or nouveau? Looks to be the later ...
13:57 ccaione: rhyskidd_: NVIDIA blob
14:02 rhyskidd_: ok
16:50 karolherbst: \o/
16:51 karolherbst: KHR-GL44.copy_image.functional passes now for those formats
16:53 imirkin: cool, what'd you do?
16:53 karolherbst: for f32 exponent -15 to -18 I do this: uf11 = (4 << (exponent + 18)) + (4 * (mantissa >> (23 - (exponent + 18))));
16:53 karolherbst: pimping f32_to_uf11
16:54 imirkin: where is this? in C code, or in gpu code?
16:54 karolherbst: C yeah
16:54 imirkin: i guess it's not using the PBO stuff, so C code
16:54 karolherbst: src/util/format_r11g11b10f.h
16:54 karolherbst: sw fallback path
16:54 imirkin: fun.
16:54 karolherbst: yeah......
16:54 karolherbst: no
16:54 karolherbst: I needed like 3 hours to get my head around this f32 to f11 conversion stuff
16:56 karolherbst: duh...
16:56 karolherbst: now I have an issue with GL_R11F_G11F_B10F and GL_RGB9_E5
16:58 imirkin: well, f11 is ... sign bit + f10, which in turn is the same as f16 with just 6 fewer bits of mantissa.
16:58 imirkin: er, 5 fewer bits
16:58 karolherbst: no
16:58 karolherbst: unsigned
16:58 imirkin: yes. f10 and f11 are both unsigned, my bad.
16:59 karolherbst: but yeah, same exponent
16:59 imirkin: but they're still like f16 - just with no sign bit and less mantissa. same exponent.
16:59 karolherbst: reduced mantissa
16:59 imirkin: we take advantage of that in the GPU logic to convert F10/F11 to F32.
16:59 imirkin: since we bitshift it to F16 and then use F2F to go from F16 to F32
16:59 karolherbst: sounds reasonable
17:00 karolherbst: but what I don't understand is, why mesa does conversions here as well
17:00 karolherbst: it simply does a f11->f32->f11 conversion directly
17:00 imirkin: probably because it's easier
17:00 karolherbst: well, srcFormat == dstFormat -> do nothing
17:00 karolherbst: the information is there
17:01 karolherbst: okay, that other tests already failed without my tinkering
17:02 imirkin: =]
17:02 karolherbst: but dest is now GL_RGB9_E5_EXT
17:02 karolherbst: and src is GL_R11F_G11F_B10F
17:03 karolherbst: the test prior this was dest GL_R11F_G11F_B10F and src GL_UNSIGNED_INT_10_10_10_2 I believe?
17:03 imirkin: well, src doesn't matter right?
17:03 karolherbst: you think
17:03 imirkin: the issue is that glGetTexImage normalizes the values in the texture before returning client data, right?
17:03 karolherbst: it also getTexImage the src
17:03 karolherbst: okay here is what the test basically does:
17:04 imirkin: you determined that the values in the real texture were fine
17:04 imirkin: it's just the data returned by glGetTexImage that's bad
17:04 karolherbst: create texture, copy tex1 to RB, copy RB to tex2, read tex1 and compare with original data, read tex2 and read with expected data
17:04 karolherbst: *compare
17:04 karolherbst: yeah
17:04 karolherbst: but it also reads the src
17:04 karolherbst: to see if somebody bad happened to it
17:04 imirkin: ok, fair enough
17:04 karolherbst: *something
17:05 karolherbst: good thing is, with qapitrace I get the real value anyway
17:12 karolherbst: imirkin: okay, that GL_R11F_G11F_B10F -> GL_RGB9_E5_EXT indeed produces wrong results, it's 0x0 in memory, but should be 0x60000000
17:12 karolherbst: well at least qapitrace tells me it is 0x0
17:13 karolherbst: no idea how it parses that E5 part
17:15 karolherbst: fun, also 0 on nvidia
17:24 karolherbst: I think I go for the easier fix and just skip the conversion if we don't have to
17:24 karolherbst: should save CPU overhead as well
17:29 karolherbst: and I don't see a way how to fix this anyhow
17:29 karolherbst: if RGB are all 0, and there is just an exponent
17:29 karolherbst: we always get 0 as the result
18:02 karolherbst: \o/
18:03 karolherbst: Test case 'KHR-GL44.copy_image.functional'.. Pass (Pass)
18:03 karolherbst: 395s run time
18:06 karolherbst: imirkin: now idea if we really can do this, but with this patch copy_image passes at least: https://github.com/karolherbst/mesa/commit/b7fad78fd38b31997717dda34b1d2649e48856ff
18:07 karolherbst: otherwise we mesa would convert src to rgba first and back to the dest format, even if src and dst have the same format
18:07 karolherbst: which is super annoying for GL_RGB9_E5_EXT
18:15 imirkin: why the dst_format_is_mesa_array_format thing?
18:15 imirkin: anyways, i don't know that code at all
18:15 imirkin: get jekstrand to look at it
18:27 karolherbst: imirkin: because imagine this: GL_RGB9_E5_EXT to GL_RGBA to GL_RGB9_E5_EXT for value 0xc0000000 ends up as 0
18:27 karolherbst: and I don't see why we even have to convert to RGBA in the first place
18:27 karolherbst: for different formats: okay fine, but why if src and dest format matches?
19:59 karolherbst: imirkin: do you know why the CTS thinks the GL_EXT_shader_integer_mix extension isn't supported? it's weird, because everything looks just fine
20:07 karolherbst: or well, rather why KHR-GL45.shaders.shader_integer_mix.prototypes just fails as not supported
20:10 karolherbst: duh... GLSL version is 330
20:10 karolherbst: why
20:13 karolherbst: boah ey...
20:14 karolherbst: broken test again
20:15 karolherbst: hardcoding that this test is for 3.3 and then later checking against set variable if it's 4.5 or higher
20:15 karolherbst: .... smart
20:50 mangix: karolherbst: I bisected the faulty commit. Apparently it's this one: https://github.com/karolherbst/nouveau/commit/b63365aa65a6ed92b2b22c5f23cd642e3c569a8f
20:50 mangix: context: before the commit, I get an MMIO read error of 40912c. now it's 022554
20:51 karolherbst: ohh
20:51 mangix: i'm guessing some secureboot issue
21:02 imirkin: karolherbst: there was a bug iirc
21:02 imirkin: at the time i couldn't fix it, but now i guess we can
21:02 karolherbst: meh... imirkin any idea how to solve the KHR-GL45.limits.max_fragment_input_components test where we need 128 components instead of 124?
21:03 imirkin: yeah. we need to advertise 128
21:03 karolherbst: imirkin: dirty hack: https://github.com/karolherbst/VK-GL-CTS/commit/92fae1c821e02d4aeb6bcc925ad47350359214c0
21:03 imirkin: the 128 counts the gl_Position
21:03 karolherbst: imirkin: ohh, so we can simply do that?
21:03 imirkin: yes.
21:03 karolherbst: k
21:03 karolherbst: easy
21:03 imirkin: but we can't expose (128/4) MAX_VARYINGS
21:03 imirkin: it has to be 124/4
21:03 karolherbst: mhhh
21:03 imirkin: so ... some hookup required.
21:03 karolherbst: same CAP?
21:04 imirkin: probably need to add a new cap
21:04 karolherbst: yeah, I meant if it's covered by the same
21:04 karolherbst: but it's looking rather good now regarding CTS
21:04 karolherbst: basically <50 tests failing for 4.5
21:04 karolherbst: some issues when running everything at once
21:05 imirkin: cool
21:05 karolherbst: I think you also fixed a few things
21:05 imirkin: try to keep track of your investigations on the CTS board maybe?
21:05 karolherbst: running without your patches, cause they introduce other messups
21:05 karolherbst: imirkin: already doing that
21:06 imirkin: that 'cts' branch has a bunch of BS commits on it, unfortunately
21:06 imirkin: most can't be upstreamed
21:06 karolherbst: yeah
21:06 karolherbst: I have my own one where I keep only usefull things for now
21:06 imirkin: like the RA stuff is still half-baked
21:06 imirkin: needs to be redone yet-again
21:06 karolherbst: current list of things which fail: https://gist.github.com/karolherbst/efc29f30cea45bbd9d9487271517c35e
21:07 karolherbst: and some things are simply bs types of fails
21:07 karolherbst: either API issues or we compile stuff we shouldn't
21:07 karolherbst: or we don't throw the right error
21:09 imirkin: yeah. annoying that that stuff is in there, but ... not a whole lot we can do about it
21:09 imirkin: i kinda wish the people with full-time jobs (and KHR access) would work on fixing those up...
21:09 karolherbst: ...
21:10 karolherbst: maybe it happens soonish
21:10 imirkin: with GL 4.6 conformance? maybe.
21:10 karolherbst: you mean the tests or mesa?
21:10 imirkin: well ... makign mesa pass
21:11 imirkin: either by fixing the tests or mesa, as appropriate
21:12 karolherbst: k
21:16 karolherbst: another bs error: "Cannot obtain glGetCompressedTextureSubImage or glGetTextureSubImage function pointer."
21:19 imirkin: odd
21:20 karolherbst: lol...
21:21 karolherbst: glw::GenericFuncType RenderContext::getProcAddress (const char*) const
21:21 karolherbst: return (glw::GenericFuncType)DE_NULL;
21:21 karolherbst: ..........
21:22 karolherbst: what should I think about stuff like this
21:23 karolherbst: "yeah test fail because we compare NULL with NULL and then we simply report fail"
21:28 karolherbst: m_context.getRenderContext().getFunctions().X is the way to get those pointers...
21:30 karolherbst: still fails though
21:31 karolherbst: and in another test I get those func pointers
21:38 karolherbst: I think fixing those KHR-GL45.pipeline_statistics_query_tests_ARB tests is the best I can do now, because most of the failing test are indeed just silly things I get annoyed just by looking at it
21:56 imirkin: karolherbst: prepare to be frustrated with those as well.
21:57 imirkin: karolherbst, you could also make a tested counterpart to the fp64 patches that are currently in my tree.
21:58 imirkin: (the ones in my tree are for gk110... need to also do gf100, gk104, and gm107)
21:58 imirkin: gf100/gk104 should be identical though
23:32 imirkin: skeggsb: opinions on my MSI "fix" for BE?
23:32 imirkin: bit of a hack, but short of someone caring ... it does seem to be broken
23:34 skeggsb: yeah, i'll merge it as-is i guess, we don't have any better solution
23:36 imirkin: enough barriers to getting things going on BE :)