04:48imirkin: [85168.932927] nouveau 0000:04:00.0: ltc: LTC1_LTS0: 236f0030 [EVICTED_CB ILLEGAL_COMPSTAT]
04:48imirkin: skeggsb: --^ any clue what that means?
04:48imirkin: saw a bunch of those with bindless on maxwell in dirt rally
05:02imirkin: alright, well other than those messages, bindless seems to work. DOW3 and DiRT Rally tested, same as on kepler.
05:04Benau: ...now not sure if you remember my tbo issue in gt240...
05:07imirkin: Benau: i remember it
05:07imirkin: but i already had the bindless code all written, and a maxwell board plugged in
05:07imirkin: so you can guess what took priority :)
05:13imirkin: i'll try to take a look at the tbo issue tomorrow
05:13imirkin: getting late here.
05:22Benau: ok see ya
15:10imirkin: was there other maxwell stuff i was supposed to look at, while i have it plugged in? otherwise i'm going to plop the G92 back in (or another tesla)
15:11Benau: test current stk if it runs well on maxwell lol
15:12Benau: is sample-depth-texture-with-depth-buffer-bound-for depth testing undefined?
15:12pmoreau: imirkin: If you insist O:-), there is always https://bugs.freedesktop.org/show_bug.cgi?id=100177 though I haven’t checked recently whether this is still an issue.
15:13Benau: if depthmask is false(read only depth test)
15:13imirkin: Benau: you can definitely sample a depth texture. however if you have compare-to-R set on it, not sure if that's legal.
15:13imirkin: Benau: that said, pretty sure it works on nvidia. but on some hw it won't
15:14imirkin: i think other drivers might detect the situation and deal with it, so as long as you don't sampler2D it *and* sampler2DShadow in the same shader, you should be ok
15:14imirkin: (with the same texture bound)
15:15imirkin: pmoreau: the same thing as the valley issue right?
15:15imirkin: i'll check valley, but i'm sure it's still busted.
15:15imirkin: i haven't touched anything related to that
15:15Benau: ok i just use nearest filter
15:16pmoreau: imirkin: I don’t remember if I checked Valley, but hakzsam seemed to suggest it could indeed be the same issue.
15:17imirkin: yeah, i still get weird shit in valley
15:17imirkin: feels like a depth-testing thing
15:17imirkin: but wow. 40fps. i don't think i've run it in a long time.
15:18imirkin: and probably never with reclocking in place
15:18imirkin: looks a lot better than the usual 4fps i used to get
15:18pmoreau: Still the same issue in XCOM with Mesa 17.3, gonna try again with the forced flush
15:18pmoreau: 40fps, nice! :-)
15:18pmoreau: Which Maxwell do you have to get reclocking? A v1 I guess?
15:18imirkin: GTX 745 or something
15:19imirkin: and this was with a debug mesa build too... dunno if it matters
15:20imirkin: (quality high, 4x msaa, 640x480)
15:20pmoreau: I have the issue with a release version (though it is not the very latest, since it’s a 17.3 build)
15:20imirkin: GK208 works great with it
15:20imirkin: 20fps though.
15:20imirkin: oh, but like 30 in some scenes.
15:22imirkin: holy crap. with opt build, i get 50-60fps in that configuration on the GTX 745
15:22pmoreau: (Grrr, I have to figure out why git and yaourt are displaying their messages in French on my test computer, this i super annoying and weird!)
15:22imirkin: env | grep LC
15:23pmoreau: 50-60 is a bit better :-D
15:23imirkin: look for the "fr_FR" one
15:23pmoreau: `env | grep LC` => LC_COLLATE=C
15:23imirkin: env | grep LANG
15:24pmoreau: LANG=en_GB.UTF-8; LANGUAGE=en_GB:en_US:fr:de
15:24imirkin: i got nothing.
15:24imirkin: *it knows*!
15:24pmoreau: I guess it doesn’t recognise en_GB or en_US and then defaults to fr
15:25imirkin: yeah, dunno what "LANGUAGE" is
15:25imirkin: never seen it before
15:25imirkin: i don't have it defined at all
15:27pmoreau: LANGUAGE=en_GB:en_US:de git status, I get it in German, so this was it. By why does it not recognise “en_GB”, “en_US” nor “en”? Oo
15:28pmoreau: Anyway, thanks for the tip for `env | grep LANG`: I had only looked at LANG and LC* vars
15:31imirkin: yeah, when weird shit is going on, just look at ALL the environment ;)
15:31imirkin: coz if it's not there, you'll never find it - some random file in /etc
17:00hakzsam: imirkin: can you remember me which instructions can return more than one def on gm107?
17:00imirkin: well, tex & co obviously
17:01imirkin: i think karol's thing is about flags
17:01imirkin: and a ton of instructions can set the condition code
17:01imirkin: like regular ALU ops (like add)
17:01imirkin: (flag == condition code)
17:02imirkin: i think like VOTE can return both a flag and reg
17:02imirkin: er, both a pred and a reg
17:03hakzsam: just trying to understand my own code :D
17:03imirkin: btw, note that on nvc0+, "flags" is this single-bit thing
17:03imirkin: but on nv50, flags is a multi-bit thing, more like EFLAGS on x86
17:04imirkin: and also on nv50 there are 4 of them, nvc0 there's just the one
17:04imirkin: (but no pred regs on nv50, can't win 'em all)
17:06hakzsam: well, but for tex instructions, defs are packed so there is only one def right?
17:07imirkin: good point.
17:07imirkin: so ultimately it's just like vote, flags, and maybe a handful of weird cases
17:07hakzsam: okay, I will look at the emitter again
17:08imirkin: flagsDef is the thing to look for re flags
17:08imirkin: stuff like emitCC() to define, emitX() to consume
17:09hakzsam: yeah, the $c flags or something
17:09hakzsam: ie. FILE_FLAGS
17:10hakzsam: right, vote can return a GPR and a predicate
17:11hakzsam: so we have to iterate over all defs in this situation
17:11imirkin: i think karol's thing was regarding MAD
17:11imirkin: which i'm guessing is the 64-bit variant, which will make use of flags iirc
17:12imirkin: vote returning both is going to be incredibly rare
17:12imirkin: but it sounded like you weren't handling flags properly
17:12hakzsam: maybe rare, but I guess it will fail now
17:12hakzsam: yep, missed FILE_FLAGS
17:12imirkin: which is really the thing to worry about, since that's quite common
17:13imirkin: thanks for taking a look btw :)
17:27hakzsam: imirkin: nice work for bindless on maxwell btw :)
17:27imirkin: thanks. pretty simple addition on top of the kepler stuff.
17:29hakzsam: so the gallium interface I wrote fits well for nouveau as well?
17:29imirkin: yeah, i was able to make it go
17:30imirkin: a couple of minor bugfixes found along the way
17:30imirkin: and some non-intuitive bits about lifetimes
17:30imirkin: i think eventually we maybe should move off my approach with TIC/TSC as the handle
17:30imirkin: and instead do a small BO with the info and just pass in the VA like everyone else
17:37hakzsam: imirkin: while I'm at it, just two nitpicks for the bindless patch, not sure if can review the SUQ lowering though
17:39hakzsam: someone updated the GSoc ideas for nouveau
17:39hakzsam: "Initial Nouveau Vulkan driver" outch, good luck :D
17:41hakzsam: mupuf: ^ not sure if this should be a gsoc idea, it's really hard and in 3 months, definitely not doable
17:41imirkin: definitely not for a gsoc person
17:42imirkin: for someone well-versed in nvidia stuff, it should be quite achievable though
17:43hakzsam: maybe ben is working on,
17:44hakzsam: imirkin: any news of dboyan btw?
17:45hakzsam: the gm107 sched code calculator can still be improved, gsoc idea?
17:47hakzsam: should be a part of "Instruction scheduler" actually
17:52imirkin: hakzsam: no
17:52imirkin: [news of dboyan]
18:10imirkin: hm. KHR-GL45.shader_image_load_store.basic-allTargets-loadStoreVS -- hits an issue in coalesceValues on maxwell.
18:12imirkin: oh. something off with 1d textures i guess?
18:15imirkin: oh ooooops. i thought i had even debugged this before with karol. o well.
18:15imirkin: the fix never made it out
18:28adfeno: Hi all! ;)
18:28adfeno: Does nouveau support display color management?
18:29imirkin: nouveau supports LUTs that can be programmed
18:32BootI386: I managed to find a "minimal" reproducible way to trigger the crash I'm experiencing
18:33imirkin: lookup ... table
18:33imirkin: (wtf is the "U"? i've been saying LUT so long, that i've forgotten)
18:33adfeno: Ah, OK
18:33imirkin: basically for each color, independently you have a 256-sized lookup table which can remap colors however
18:33adfeno: imirkin: *L*ook*U*p *T*able?
18:34imirkin: this can be used to implement a gamma ramp, or just a straight-up brightness change, or anything else
18:34imirkin: but it can't be used to mix colors
18:34imirkin: for that you need a CSC, which, while supported by kepler+ hw, is not currently exposed by nouveau
18:35imirkin: also there's some "white point" thing that can be exposed in a monitor's EDID, but i'm not sure how that maps onto the real world
18:36adfeno: But, can I for example, go to the system properties, and change the color profile used by my display (for example, from sRGB to some CMYK like the ones from FOGRA) ?
18:36BootI386: I only needed Xorg, a WM (mutter), a game, and a little bash script that resizes the game window very very quickly
18:37imirkin: adfeno: that's not something for nouveau to support -- that's a frontend application type of thing
18:37imirkin: which in turn would implement that by messing with the LUT
18:37imirkin: BootI386: there were reports that resizing windows destroyed the universe, yeah
18:37BootI386: The funny thing is that it crashes sooner when runned under the lowest power state (07), so it's probably a race condition
18:38imirkin: BootI386: iirc it was an issue with multiple drivers, so definitely check if an update helps
18:40BootI386: I'm using Mesa master, xf86-video-nouveau master, kernel 4.15.2 with nouveau module branch 4.15
18:41imirkin: ok :)
18:46BootI386: What else can I do? :)
18:47imirkin: what's the issue exactly?
18:49imirkin: karolherbst: can you flush out some of your patches? like the samples one for example
18:53BootI386: iminkin: http://termbin.com/stbo
18:54imirkin: well that sure is unfortunate.
18:54imirkin: ok ... so ... let's see what's going on
18:54imirkin: you're running mutter?
18:54BootI386: And it freezes everything until i kill the app, of course :)
18:55imirkin: ok, so it's the app that hangs things, not mutter. that's nice.
18:55imirkin: what is the app?
18:55BootI386: Life Is Strange
18:55imirkin: e.g. can you reproduce this with, say, glxgears?
18:55BootI386: No, I can't
18:55imirkin: coz that'd be a whole lot easier to debug :)
18:56adfeno: imirkin: Thank you for the help, I have tested here and it works ;)
18:56BootI386: It's a fat but not so fat game
18:56imirkin: yeah, i'm mildly familiar with it
18:57BootI386: I wrote a lib to avoid the painful need of lauching steam
18:58BootI386: So that I only have the minimal setup to see if it crashes
18:59imirkin: what if you make an apitrace
18:59imirkin: and then replay that apitrace
19:00imirkin: (and mess around with apitrace's window)
19:00imirkin: basically ... i want to simplify
19:00imirkin: as much as possible
19:00imirkin: i'm afraid this is some sort of nasty winsys interaction
19:00imirkin: and winsys is the area of the stack i know by far the least about
19:01BootI386: Oh, good idea. I tried to make it crash directly while tracing the game, but it doesn't want, I guess apitrace is slowing down things too much.
19:02imirkin: could b.e
19:02imirkin: so assuming it's not a totally ridiculous game
19:02imirkin: it's drawing to a backbuffer, and then flips that
19:03imirkin: now, what happens to these buffers when the window resizes?
19:03imirkin: have you noticed if it's when making the buffer larger or smaller or doesn't matter?
19:07BootI386: I can't really tell (my script sets a new size randomly each 10ms), but when it freezes, the (visible) viewport is always too big to fit inside the window iirc
19:08imirkin: ok, so it's on a resize down.
19:08imirkin: can you get a trace of the application in an area where it dies? i want to see how it draws stuff to the frontbuffer. i assume a blit from fbo at the very end, but who knows.
19:08imirkin: er, s/frontbuffer/winsys buffer/
19:09Flat: Hello, when using the nouveau driver instead of nvidia for a GTX 650 Ti Boost the system hard locks after about 5min. Only reset button works. https://bpaste.net/show/14944655bc7f I believe it's related to bugs 93629, but there hasn't been any progress that I see. Any work arounds currently?
19:09imirkin: (it doesn't have to actually die while doing the trace, i just want to see what kinds of things it's doing)
19:10imirkin: Flat: is that the bug where some people with GTX 660's have to use blob ctxsw fw?
19:10Flat: I think so yes
19:10imirkin: and does that help you?
19:10Flat: To be honest, it's been a while since I've tried and I couldn't find the steps to use it
19:10BootI386: Ok, I'm trying this
19:10BootI386: Do you know if I can lower even more the power level?
19:11imirkin: Flat: https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware
19:11imirkin: (the firmware is extracted by that script)
19:11Flat: Thank you imirkin I'll give that a shot and see if I still get the freezes
19:11imirkin: (even though your issues have nothing to do with the video decoding accel... the script grabs it)
19:11imirkin: hopefully they haven't taken down 325.15
19:12imirkin: BootI386: using a pstate that's not in your vbios would be a bit involved
19:14Flat: Wasn't there some kernal params you had to pass on boot too for the blobs? Maybe I'm just missing it on this page
19:14imirkin: Flat: yes, there is
19:14BootI386: I have a GK107, btw
19:14imirkin: Flat: nouveau.config=NvGrUseFW=1
19:14Flat: Great, thank you
19:19BootI386: HAH! Got a crash while tracing
19:19BootI386: *hopes the trace isn't corrupted*
19:20imirkin: you don't even need to mess with the resizing stuff
19:21imirkin: i just wanted to generally see what it looked like
19:24Flat: So far so good looks like with the blobs. Some errors on loading some firms looks like though, not sure if that's normal. https://bpaste.net/show/365c9e049f7c
19:25imirkin: Flat: expected. you have the old filenames, so it falls back to them
19:25imirkin: (i never updated my script for the "new" filenames)
19:25Flat: Ah, gotcha.
19:26imirkin: do you get acceleration and it all works ok? e.g. run "glxinfo" and ensure it talks about nouveau and not llvmpipe
19:27Flat: Yup "OpenGL vendor string: nouveau" seems like all is well. Provided the freezes don't show back up I'll stick with nouveau. Especially the since the latest nvidia has serious regression issues for me, using chromium anyway.
19:28Flat: Thanks for the help!
19:30BootI386: The last thing I have in the trace before a bunch of glClientWaitSync (at the time it crashed, I guess) is a call to glBindFramebuffer
19:30imirkin: what are the arguments?
19:31BootI386: I'm uploading the trace
19:31imirkin: to glBindFramebuffer that is
19:31BootI386: glBindFramebuffer(GL_FRAMEBUFFER, 2)
19:31imirkin: that's a FBO
19:32BootI386: Looks sadly not unusual
19:32imirkin: i was hoping for a 0
19:32imirkin: which woudl be the winsys fbo
19:34BootI386: Well, I just launched it again, to see if it happens again
19:37BootI386: What is the mesa env var that forces a flush after each GL call, again ?
19:37imirkin: only with a debug mesa build unfortunately
19:37BootI386: Guess what ;)
19:42BootI386: It happens exactly at the same place
19:48BootI386: imirkin: https://lib.bitmycode.com/LiS.trace.xz
20:04imirkin: RSpliet: any chance you could test https://patchwork.freedesktop.org/patch/202553/ on your fermi?
20:07BootI386: imirkin: I tried with MESA_VERBOSE=all and it seems it gets stuck at _mesa_bind_framebuffers(), so the same place as apitrace
20:08imirkin: BootI386: your trace ends with a ton of glGetQueryResult
20:08BootI386: Yes, ignore them, they all timed-out
20:09imirkin: it seems to be doing some pretty questionable stuff
20:09imirkin: like calling glClientWaitSync in a loop with a timeout of 0
20:10BootI386: Call #493061 is close before the glGetQueryResults
20:10imirkin: 493064 glBindFramebuffer(target = GL_FRAMEBUFFER, framebuffer = 2)
20:11imirkin: is that the "final" call which causes the death?
20:11imirkin: this seems like the flip sequence
20:13BootI386: http://termbin.com/d6rs here are the logs with MESA_VERBOSE=all, you can see that the last Mesa function called is _mesa_bind_framebuffer()
20:13imirkin: let me read some st_manager code
20:13imirkin: try to figure out how it's all meant to work...
20:15BootI386: Ok :)
20:21imirkin: this might all require the help of someone who knows how this is all supposed to work in the first place
20:22BootI386: git blame? :)
20:22imirkin: oh hey - are you using DRI2 or DRI3?
20:22imirkin: (did you enable DRI3 in your xorg.conf?)
20:23imirkin: can you ...
20:23imirkin: (a) try with LIBGL_DRI3_DISABLE=1
20:23imirkin: (b) try with xf86-video-modesetting
20:23imirkin: DRI3 is a bit sketchy on xf86-video-nouveau
20:24BootI386: Ok, I'll do that in a couple of minutes
20:27rhyskidd: mupuf: thanks for the shout out at FOSDEM, you did pronounce it correctly
21:02pmoreau: Awesome, I managed to break everything when compiling from source, with my recent rebase. --'
21:04BootI386: imirkin: It seems it does not crash with DRI3 disabled
21:04imirkin: BootI386: ok, good to know
21:04imirkin: BootI386: what about with xf86-video-modesetting?
21:06pmoreau: WTH, if I dump the SPIR-V to a file to look at it later on, that avoids a trap on the GPU?! What have I done Oo
21:07BootI386: Just a second…
21:07BootI386: Crash !
21:08imirkin: BootI386: ok, so it's nothing that xf86-video-nouveau is doing. good.
21:08imirkin: [or not doing]
21:11pmoreau: Found it! I made a mistake and ended it running 32-bit pointers on GPUs with 64-bit addressing --"
21:12imirkin: does that even matter :p
21:13pmoreau: Well, when you are passing pointers around, yes :-)
21:13pmoreau: as arguments to functions
21:14BootI386: Yes, the crash is reproducible with modesetting too
21:14BootI386: Well, actually it's even worse
21:14BootI386: Killing the app or Xorg is not enough
21:14pmoreau: If the code expects two 64-bit pointers, but you give it two 32-bit ones, then the first pointer read ends up being a combination of the 2 you gave it, and the second one is just reading random data.
21:14BootI386: A reboot is needed :)
21:16BootI386: So yeah, it's not DDX-specific but maybe inside the common DRI3 path inside Mesa?
21:16imirkin: yeah, likely
21:17imirkin: and probably something nouveau-specific
21:17imirkin: not sure how
21:19BootI386: Doesn't it look like a race condition… somewhere inside the module
21:22BootI386: I'm not sure how I could help further
21:30BootI386: Any idea imirkin?
21:58imirkin: BootI386: hm. there are a few places where we do stfb->stamp++, but curiously use p_atomic_read() to read it back out.
21:58imirkin: BootI386: you could try using p_atomic_inc() instead
21:58imirkin: (in st_manager.c)
21:58imirkin: seems unlikely to matter though
21:59imirkin: BootI386: also perhaps you could throw a bunch of prints into st_framebuffer_validate -- this is where the resizes happen
22:03BootI386: Ok, thank you, I'm trying this
22:07BootI386: Still crashes with p_atomic_inc()
22:11karolherbst: imirkin: which ones? I don't have time right now, but I will check tomorrow
22:17imirkin: karolherbst: mainly https://github.com/karolherbst/mesa/commit/f8fcd8da39e91d773382c2ca9acdddc7c1a28854
22:22BootI386: imirkin: Got this just before the crash : http://termbin.com/kpbg
22:27BootI386: Before : http://termbin.com/i18d
22:27BootI386: Just before : http://termbin.com/hegx
22:28BootI386: git diff between those : http://termbin.com/tvnl
22:31imirkin: it becomes a width=1 buffer?!
22:32BootI386: Right :)
22:32imirkin: yeah, i dunno what that's all about
22:32imirkin: wait, is that you resizing it?
22:33imirkin: i mean, did you resize it to width=1?
22:33BootI386: No, I resize it to width *and* height = 1
22:34BootI386: I'll try with 100, to be sure the problem is not this size
22:44BootI386: It also crashes with 1920x1080/100x100
22:44imirkin: does it think it's a 100x1080 buffer?
22:45imirkin: coz that could definitely be problematic
22:47BootI386: I'm retrying, to see if there is a pattern
22:51BootI386: This time, just before the crash, I get 100x100, and it was the final size of the window displayed on the agréent…
22:55BootI386: Oh, wait, I should try something
23:00BootI386: No, nothing interesting
23:20BootI386: imirkin: Adding two fprintf() inside _mesa_bind_framebuffers() is enough to make the crash really hard to trigger