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