18:47tobijk: somebody already investigated render corruptions with generations after kepler? https://homepages.thm.de/~tjkl80/Screenshot_20170814_204553.png
18:51karolherbst: tobijk: this is valley, right?
18:51imirkin_: tobijk: sounds familiar. iirc MESA_DEBUG=flush helps
18:52pmoreau: imirkin_: Thinking of this one? https://bugs.freedesktop.org/show_bug.cgi?id=100177
18:52tobijk: imirkin_: karolherbst: yep its valley, but i have other "apps" where corruptions are visible
18:53imirkin_: pmoreau: yes, i am.
18:53karolherbst: tobijk: did you check with NV50_PROG_OPTIMIZE=0?
18:53tobijk: karolherbst: not yet with valley, sec will test
18:53karolherbst: but this hardly helps, at least for me on kepler
18:55tobijk: yep the corruptions are still visible with MESA_DEBUG=flush or NV50_PROG_OPTIMIZE=0
18:55tobijk: so its likely some insn not emmited properly?!
18:56karolherbst: could be anything
18:56karolherbst: check dmesg
18:56tobijk: dmesg is clean
18:57karolherbst: I could check with my kepler if everything is alright
18:57karolherbst: just currently doing a CTS full run and it might take some time until I can do anything
18:57tobijk: karolherbst: its a longer standing issue, having it since switching from kepler to pascal
18:58tobijk: i would suspect kepler is just fine :)
18:58karolherbst: most likely
18:59tobijk: karolherbst: but double checking later on would be nice, its around 20sec in after starting
19:00karolherbst: I hate those KHR-GL45.arrays_of_arrays_gl.InteractionFunctionCalls* tests
19:00karolherbst: they take like forever
19:01karolherbst: well, I think I can simply start valley, should be fine
19:01imirkin_: tobijk: you know, it feels like one of those saturation issues ;)
19:02imirkin_: that karol just fixed
19:02imirkin_: is this against latest master?
19:02tobijk: imirkin_: yep
19:02imirkin_: although those would have gone away with NV50_PROG_OPTIMIZE=0
19:02tobijk: imirkin_: nope its worse with OPTIMZE=0
19:02imirkin_: lol, that's bad!
19:02karolherbst: tobijk: qhat quality levels?
19:03karolherbst: well, with OPTIMIZE=0 we also fail more CTS tests, so ;)
19:03imirkin_: could be a RA issue
19:03tobijk: karolherbst: Ultra, stereo disabled, 1024x768
19:05karolherbst: well I am sure it at least used to work on kepler
19:05tobijk: karolherbst: it did!
19:05tobijk: does it not?!
19:05karolherbst: no issue
19:05karolherbst: well "no". There are some oddities
19:06imirkin_: btw, i think MESA_DEBUG=flush only works in a debug build
19:06imirkin_: is this a debug build?
19:06tobijk: ah heh, nope
19:07karolherbst: I think there is an issue we also have with heaven
19:08karolherbst: some kind of "overlay" above distant things, looking like some kind of net or so
19:08karolherbst: but this could also be super normal
19:08tobijk: imirkin_: ok, you were right, flush does indeed remove the corruptions
19:09karolherbst: tobijk: do you also see this weird thing, especially by the mountains?
19:09tobijk: purple overlay?
19:09karolherbst: I will give a screenshot
19:09imirkin_: tobijk: unfortunately i haven't the faintest clue how to go about debugging stuff like that
19:10imirkin_: we're clearing missing a flush or something somewhere
19:10imirkin_: but ... where ... and why
19:10imirkin_: without proper docs, this is extremely tricky to RE
19:10imirkin_: (read: time-consuming)
19:10imirkin_: and i don't have that kind of will power
19:10tobijk: hmm, already figured
19:10karolherbst: tobijk: https://i.imgur.com/hKgK8LR.jpg
19:10karolherbst: tobijk: see those "lines" on the montains
19:11karolherbst: they are fixed related to the viewport, but if the scene moves, it looks like they are moving down
19:11karolherbst: could be issues with their blur effect
19:12tobijk: *still watching*
19:12tobijk: oh right, there it is
19:12tobijk: cant remember those issues, but that does not mean too much :D
19:13karolherbst: they are there forever afaik
19:13karolherbst: and I think I decided those are totally fine
19:13karolherbst: but never investigated those
19:13tobijk:is going to add flushes like everywhere ;-)
19:14karolherbst: imirkin_: do you know if nouveau/codegen just stucks somewhere with KHR-GL45.arrays_of_arrays_gl.InteractionFunctionCalls?
19:14imirkin_: i haven't debugged it
19:29karolherbst: I always forget, that some of those tests are not part of 4.5 and only extensions they added there for fun
19:30imirkin_: AoA was in 4.4 though, no?
19:30karolherbst: yeah, was more related to other issues
19:30imirkin_: er no, it was 4.3 :)
20:39thican: Hello everyone. rhyskidd asked me the other day to report issue if I have some problems with Nouveau driver with my GP107 (GTX 1050 Ti)
20:39imirkin_: what kind of issue?
20:39thican: When I played the game Terraria, I noticed huge lags during the play
20:40imirkin_: did you clock your GPU up?
20:40thican: imirkin_: I don't think so, I don't remember tweaking anything
20:40imirkin_: using kernel 4.12+?
20:40imirkin_: cat /sys/kernel/debug/dri/0/pstate
20:41imirkin_: [pastebin that]
20:41thican: linux firmware 20170622
20:41imirkin_: oh wait. GP107.
20:41imirkin_: not GM107.
20:41imirkin_: ignore all that.
20:41thican: No file :-)
20:41imirkin_: anyways, you should expect things to be pretty slow
20:41thican: so, when I switched back to nvidia drivers, the game was okay
20:42imirkin_: nvidia has not released firmware that enables one to switch to non-boot clocks, which are almost universally very low
20:42thican: I noticed this message (I didn't copy it): not using EXT_swap_control_tear for Vsync
20:42thican: with Nvidia, I have this: Using EXT_swap_control_tear VSync!
20:42imirkin_: yeah, that's not supported on mesa
20:42thican: ah :/
20:43thican: so, you are saying it still requires the signed firmware from Nvidia?
20:43thican: or this is something to be implemented?
20:44imirkin_: well, signed firmware is required no matter what
20:44thican: yes, I mean
20:44thican: "another" one?
20:44imirkin_: we can develop all the firmware we want, nvidia will never sign it
20:44imirkin_: it requires firmware for the pmu that nvidia has not released.
20:44thican: they don't need to sign it if we have the key ;-) (j/k)
20:44imirkin_: [i believe they have a dummy pmu blob]
20:44imirkin_: it'd also be impossible to develop without being able to test stuff
20:45thican: but I understood we got the signed firmware, right?
20:45thican: So, what blocks us now?
20:46thican: (FYI, I have huge freeze sporadicly with _nvidia_ drivers, and I would like to move on)
20:46thican: and with nvidia drivers, I have a low resolution on TTY, while with Nouveau I have nice resolutions for TTY
20:47imirkin_: if you want well-supported graphics on linux, i'd recommend AMD
20:47thican: ah? Did it change?
20:47thican: It might be a while, but I remember people telling us to avoid AMD
20:48imirkin_: from like 6 years ago? yeah
20:48thican: yes, maybe
20:48imirkin_: yeah, ATI was a disaster on linux
20:48imirkin_: although i did get VIVO working on my radeon 7000 back in the day ;)
20:48thican: I still do the difference between ATI and AMD, the first for GPU the second for CPU :-)
20:49imirkin_: well, i think r600 was an ATI design. the GCN stuff is well post-acquisition
21:21karolherbst: imirkin_: okay, no pipeline_statistics_query_tests_ARB fixes, because it's 4.6 :)
21:21imirkin_: we could stop exposing the ext
21:21karolherbst: we could
21:25karolherbst: imirkin_: todo list for 4.4: https://trello.com/c/qtJ5jkZh/13-failing-tests-wip
21:26imirkin_: you mean 4.5?
21:26karolherbst: no 4.4
21:26karolherbst: those lists are the same
21:26imirkin_: khr_debug is 4.6 as well
21:26karolherbst: just the 4.5 has more
21:26imirkin_: not sure how you're categorizing these
21:26karolherbst: khr_debug is 4.3
21:27imirkin_: what's 4.6 then?
21:27imirkin_: oh. khr_no_error.
21:27imirkin_: basically the same ;)
21:28imirkin_: where are all the 3d images tests that fail?
21:28imirkin_: oh, that's probably the non-layered binding thing
21:28karolherbst: well everything else passes
21:29karolherbst: Passed: 6393/6493 (98.5%) without the skips
21:29karolherbst: and that's for 4.5
21:31karolherbst: the 4.5 mustpass lists contains all 4.4 tests, makes it easier
21:34karolherbst: imirkin_: what should we do about "internalError"? just ignore?
21:35bloblo: need help
21:35karolherbst: imirkin_: ohh right, I wanted to do that fp64 stuff
21:36bloblo: i have gtx 770, nouveau set max 5 gt/s
21:36bloblo: with lspci i have only 5 gt/s
21:36bloblo: if i blacklist nouveau and activ nvidia then i have 8gts
21:37bloblo: i have x79 board
21:37bloblo: 2 pcie3
21:37karolherbst: bloblo: there is a bug within the vbios parsing I still have to fix
21:37karolherbst: anyway on a desktop the perf benefit is... not really there
21:38karolherbst: create a bug report or something and whenever I fix this, you get notified
21:39bloblo: where i send infos ?
21:40bloblo: ok tomorow i try (is night now here)
21:47karolherbst: hum, "set $r6 ne u32 $r3 0x7ff"
21:49karolherbst: there I have to put b32
21:49karolherbst: and for the other sets, I don't
21:49imirkin_: predicate vs register
21:54karolherbst: much better
21:54karolherbst: only the mods are failing
21:55imirkin_: and that's expected
21:55imirkin_: [for now]
21:57karolherbst: "NotSupported (The test can be run only in ES context)" this makes it easy
21:59karolherbst: "The tested mode was GL_QUERY_NO_WAIT_INVERTED. Query was done for target GL_SAMPLES_PASSED, and the test was prepared to pass all fragments."
21:59karolherbst: and 3 others
21:59imirkin_: the NO_WAIT stuff may be questionable
21:59imirkin_: could be messed up in conjunction with inverted
21:59karolherbst: expected 1, resulted 0
22:00karolherbst: well, intel passes this test
22:00imirkin_: i meant in nouveau :)
22:04imirkin_: let's see...
22:05imirkin_: iirc tobijk implemented this
22:05karolherbst: easy fix
22:05karolherbst: "KHR-GL45.conditional_render_inverted.functional" pass :)
22:05imirkin_: of course non-inverted now fails :p
22:06imirkin_: hq->data = 1; /* initial render condition = true */
22:06imirkin_: does that need to change to the condition?
22:06karolherbst: imirkin_: https://github.com/karolherbst/mesa/commit/5654927f55602cfd6e50a7583275da26ebae8e0a
22:07imirkin_: so i think in *reality* what needs to happen is
22:09imirkin_: if hq->state != READY && !wait make it pass
22:09imirkin_: in nvc0_render_condition
22:10imirkin_: i.e. cond = NVC0_3D_COND_MODE_ALWAYS
22:10imirkin_: i really think that
22:10imirkin_: hq->data = 1; /* initial render condition = true */
22:10imirkin_: changing that to 0 will fix those cases.
22:11imirkin_: but unfortunately that information is not available
22:11imirkin_: at begin query time
22:24karolherbst: okay, textureGrad is a little broken
22:25imirkin_: i broke it a while back
22:25imirkin_: to fix deqp
22:25imirkin_: which caused some piglits to regress
22:25imirkin_: i never got to the bottom fo it
22:25karolherbst: well, CTS is unhappy now
22:25imirkin_: but the new code made more logical sense iirc
22:25imirkin_: this is with cubes right?
22:26imirkin_: i think i might be changing the major axis now
22:26imirkin_: whereas i'm not supposed to
22:26karolherbst: well, I will check with apitrace
22:26imirkin_: get blob shader too, could be instrucitonal
22:27karolherbst: I hope it's an obvious issue
22:27karolherbst: weird thing is
22:27karolherbst: with GL_DEPTH_COMPONENT32F it's fine
22:27karolherbst: GL_RGBA8, GL_RGBA32I, GL_RGBA32UI and GL_STENCIL_INDEX8 broken
22:29karolherbst: apitrace fails me
22:29karolherbst: crash in strlen
22:34imirkin_: ok yeah
22:34imirkin_: i think the proper fix is in nvc0_render_condition to check if the query is done, and if it's not, just set the condition to "always"
22:34karolherbst: well, just don't pass NULL to a gl function
22:34imirkin_: that's the partial fix
22:35imirkin_: the *proper* fix, is to use a macro which detects it
22:35imirkin_: [this is in re the inverted + nowait]
22:35tobijk: hmm, whats up with inverted render cond?
22:35imirkin_: tobijk: it returns the wrong result if wait==false
22:36imirkin_: and the query in question has not yet completed
22:37karolherbst: imirkin_: you remember in which commit you "fixed" the deqp tests?
22:38imirkin_: let's see
22:39karolherbst: mhh, interesting
22:40karolherbst: this commit fixed 26 sub tests
22:40karolherbst: without it: 168 fails, with: 144 fails
22:44imirkin_: so ... not all bad ;)
22:45imirkin_: anwyays, the textureGrad failures you're seeing now could be different - dunno
22:45tobijk: If <mode>
22:45tobijk: is QUERY_NO_WAIT_INVERTED or QUERY_BY_REGION_NO_WAIT_INVERTED
22:45tobijk: the GL may choose to unconditionally execute the subsequent rendering
22:46tobijk: commands without waiting for the query to complete.
22:46imirkin_: tobijk: right
22:46imirkin_: tobijk: whereas we're choosing to unconditionally not-execute the subsequent rendering commands
22:46tobijk: for me "may" sounds like: "do whatever pleases you"
22:47tobijk: but i'm wrong :D
22:47imirkin_: the alternative is that the GL impl may choose to wait for the query to complete
22:47imirkin_: but if it doesn't wait, it has to execute the rendering
23:02tobijk: so yeah, you wrote it up there already, set condition to _do_it_ :D
23:04karolherbst: that cube bug sounds like something interesting, maybe I figure something out tomorrow
23:04imirkin_: just need to look at the query state in the !wait case
23:04imirkin_: karolherbst: ok cool. feel free to ask me how the handleManualTXD stuff works -- it wasn't trivially obvious to me the first 15 times i read it
23:25tobijk: imirkin_: you are handling the cond patch, am i correct?
23:26imirkin_: maybe eventually?
23:26imirkin_: i'm busy with other stuff atm
23:26imirkin_: let me make a note of it
23:26tobijk: the failing test stays anyway :D
23:27tobijk: maybe i find the time tomorrow, but now i'm off
23:56MichaelP: Nvidia GeForce GT 730 20-nouveau.conf ... screen tearing