00:39imirkin: anyone running the blob on kepler who could do a mmt trace for me of a piglit?
11:13RSpliet: imirkin: I could, but it'll be blob 367.27
13:09imirkin: RSpliet: as long as it works :) put this through shader_runner: https://hastebin.com/wajutejeja.cs
13:09imirkin: should just be able to do bin/shader_runner foo.shader_test -fbo -auto
13:10imirkin: the test will have a result of "fail", but what i'm looking for it is to not hang, so i don't care
13:28RSpliet: [require] section missing
13:28RSpliet: Is that relevant?
13:30RSpliet: Wait... that section isn't missing
13:30RSpliet: Oh we, I'm an idiot
13:34imirkin: basically i want to see what gets compiled differently and/or how headers are set differently
13:34imirkin: coz it's not exactly a complex shader
13:35imirkin: and if i do like if (uniform) then it's all fine
13:35RSpliet: imirkin: I'm an idiot because I failed to realise you don't wget a shader by copy-pasting the URL you sent me... you wget a shader after pressing the "raw" button and copy-pasting that URL
13:35imirkin: and if i mess with the number of invocations, it's all fine
13:35imirkin: RSpliet: ah yeah, sorry!
13:35RSpliet: Not your fault ;-)
13:36RSpliet: Anyway, there's trace in your inbox. I needed -m e7 to decode it
13:36imirkin: awesome, thanks!
13:36RSpliet: (apparently not to be confused with -a e7, which is what rnn/lookup takes)
13:37imirkin: why would one confuse those two
13:37imirkin: that'd just be crazy!
13:37RSpliet: Right! ....
13:39imirkin: still haven't gotten it =/
13:40RSpliet: Oh sorry, I should have said "I sent trace to your inbox". It hasn't arrived indeed
13:41imirkin: there it is!
13:41RSpliet: It's left my mailserver now though. Don't ask
13:44imirkin: my demmt doesn't seem to like it at all =/
13:44imirkin: i don't get the command decoding
13:45RSpliet: Do you get the shader?
13:45imirkin: it's in there somewhere, but not explicitly
13:46RSpliet: Shall I demmt it for you in colour or b&w?
13:49RSpliet: Might have to rebuild envytools with lang=en_US for color :-P
13:49imirkin: got it
13:49imirkin: much better, thanks!
13:52imirkin: oh fuck them
13:52imirkin: figured out it'll only ever emit 1 vertex
13:54imirkin: RSpliet: i have to run, but will you be around tonight/tomorrow for a few more experiments?
13:55RSpliet: imirkin: I performed them on my work machine, so tomorrow is more convenient
13:55imirkin: ok cool
13:55imirkin: thanks again for the help!
13:56imirkin: btw - handy little trick with hastebin -- ctrl+shift+r gets you to the raw view
13:57RSpliet: Oh I always forget keycombos. The "raw text" button is obvious once you spot it :-)
14:12imirkin: RSpliet: https://hastebin.com/omozeselal.cs
14:12imirkin: try to optimize that, you evil blob!
14:13RSpliet:presses the raw button
14:18imirkin: my GUESS is that it bumps max vertices to 7
14:18imirkin: er, to 8
14:19imirkin: hm, nope
14:26imirkin: ok, well, i don't see anything obvious =/
14:26imirkin: thanks for getting the traces though
20:05imirkin_: skeggsb: can contexts be interrupted mid-draw on kepler?
20:06imirkin_: it seems like the GS issue i'm having only happens with weird invocations * max vertices settings, and only in lack of uniformity across invocations' execution
21:45skeggsb: imirkin_: afaik, no
21:46imirkin_: i definitely know it can't happen mid-shader-execution
21:46imirkin_: since that'd be crazy-talk
21:47imirkin_: but in the middle of a giant draw of tons of prims?
21:47skeggsb: i think it's draw-call boundaries on kepler, pixel boundaries on pascal and up
21:48skeggsb: though.. i don't believe we enable that..
21:48imirkin_: i guess i should get someone to use blob ctxsw fw and see if that fixes it
21:49skeggsb: pascal can also preempt mid-shader for pure compute too i believe
21:50imirkin_: that's nuts ... i guess it makes sense for handling page faults
21:51imirkin_: btw - i assume you have no time to debug/investigate this kepler thing?
21:52skeggsb: probably unlikely
21:54imirkin_: yeah, figured
22:02JayFoxRox: what does RDI stand for? RAM Data Interface? Raw Data Interface? RAM Debug Interface? ..
22:02imirkin_: depending on context, the "data" index register, in x86 arch
22:02imirkin_: and si is "source index"
22:02JayFoxRox: nv2a GPU
22:03JayFoxRox: PGRAPH RDI - where you can access the PGRAPH RAM (?)
22:03imirkin_: (ax = accumulator, bx = base, cx = counter, dx = data. they definitely weren't thinking "a, b, c, d"...)
22:03JayFoxRox: I know x64 lol. that's not the RDI I'm talking about
22:03imirkin_: yeah :)
22:04imirkin_: sorry, i have no useful info for you
22:04JayFoxRox: I felt the nvidia reg of the same name was implied in #nouveau :P
22:04JayFoxRox: mwk probably knows :)
22:16JayFoxRox: [if anyone knows / responds; please highlight me or /query - thanks!]
22:39mwk: JayFoxRox: who knows, one of the ones you guessed probably
23:06sgt-hartman: imirkin: Hi, i finally solved my problem!
23:06sgt-hartman: ^^ happy!
23:06sgt-hartman: you helped me in a way
23:07imirkin_: what solution worked out for you?
23:07sgt-hartman: i simply had to replace "nouveau" by "modesetting" as device driver in my xorg.conf
23:07imirkin_: it does use a slightly different method of vblanks
23:07sgt-hartman: i made lot of tests to find that
23:07sgt-hartman: yeah i suppose
23:08imirkin_: i'm surprised it makes a difference for that
23:08sgt-hartman: seems Fedora made some changes in the integration of the graphic stack
23:08imirkin_: anyways, hopefully you don't see too many problems with GLAMOR
23:08imirkin_: IME it's really good at tickling issues in nouveau
23:08sgt-hartman: i don't really understand the delta between the two drivers, nouveau worked well before
23:09imirkin_: yeah, who knows. all that stuff is so far from upstream...
23:09sgt-hartman: very complicated right
23:10sgt-hartman: I first tried with an asus flat panel instead of my good old SCART screen and had same results
23:10sgt-hartman: but noticed the problem disappeared when i disabled my xorg.conf
23:11sgt-hartman: while viewing the logs i noticed "modeset(0)"
23:11sgt-hartman: and bingo
23:11imirkin_: ah right, yeah, so as i thought, fedora defaults to modesetting with nouveau
23:11sgt-hartman: since fedora 29 i think
23:13sgt-hartman: with nouveau vsync is really broken, i had really weird results. its synced randomly with glxgears. One launch framework was at 800fps, next launch is synced correctly.
23:13sgt-hartman: and with my old monitor sometime it synced at 30fps (half)
23:14imirkin_: worksforme =]
23:14sgt-hartman: if i can help for tests don't hesitate
23:14imirkin_: i've got enough problems
23:15sgt-hartman: in think the culprit is in fedora integration more than real bug in nouveau xorg drivers
23:15imirkin_: supporting fedora, which is actively recommending things i don't recommend doesn't seem like a good use of my time
23:16sgt-hartman: maybe one day i'll switch something else. what do you think about archlinux ?
23:16sgt-hartman: switch to*
23:16imirkin_: no real opinion of it.
23:16imirkin_: it requires systemd, so it's not really on the list of options for me
23:18sgt-hartman: as a simple user i must admit systemd works pretty for me (not my purpose to launch a flamewar)
23:19imirkin_: i'm a big supporter of using whatever works best
23:19sgt-hartman: anyway its late in france, need to sleep now. Thank you very much imirkin for you help
23:19imirkin_: enjoy the mame games :)
23:19sgt-hartman: yeah, its a pleasure to play theses old arcade games on a good old crt monitor
23:20imirkin_: that's what they were designed for - the graphics look different on lcd's and so on
23:21sgt-hartman: yes, and with groovymame (a patched mame version), it generate modelines on the fly via xrandr to match the real low resolutions of theses systems