05:38 E14n: Aj2q7zDY
06:25 mupuf: well, seems like we have a problem running xonotic in ultimate mode, fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
06:25 mupuf: on the GM206
07:09 hakzsam: mupuf, missing scheduler is most likely the reason
07:09 mupuf: hakzsam: very possible :)
07:10 mupuf: I need to make changes to smartezbench to allow setting configuration options
07:10 mupuf: so you can select which GPU to use
07:10 hakzsam: nice
07:10 mupuf: you already can do it, but with the runner only
07:10 mupuf: anyway, that will be a job for later. In the mean time, we can try running more things and seeing what works or not on the maxwell
07:14 hakzsam: okay
07:14 hakzsam: the scheduler should fix a ton of issues anyways
09:04 karolherbst: yay, that shadow_warrior crash is a regression :)
09:19 karolherbst: mupuf: do you also include our private shader_db thing into your CI? Because I just found a regression there and it also contains more important shaders than the public one
09:19 mupuf: karolherbst: you want me to track if individual shaders regress in what?
09:19 mupuf: sure, I would love to add support for this though
09:19 mupuf: but shaderdb will have to be modified
09:20 mupuf: right now, shaderdb is just a performance test for me
09:20 mupuf: making sure that compilation times do not change
09:20 mupuf: at least in average
09:32 karolherbst: mhh
09:32 karolherbst: I see
09:33 karolherbst: mupuf: I just meant in running at all
09:33 karolherbst: but you should be able to track that already, cause the runner just fails to run
09:33 mupuf: what do you want to catch?
09:33 karolherbst: crashes
09:33 karolherbst: or rather "couldn't compile shader"
09:33 mupuf: then it should be covered
09:33 mupuf: as long as it just stops
09:34 karolherbst: k, but you currently just check the default shader-db?
09:34 mupuf: we should be able to handle this
09:34 mupuf:doesn't do the configuration of shader-db
09:34 karolherbst: well, but you pass a directory to run, don't you?
09:34 mupuf: it is up to the person setting shader-db's runner to add whatever shaders then want
09:34 mupuf: hmm, that is a good question
09:34 karolherbst: yeah sure, but I was talking about the nouveau CI thing ;)
09:35 mupuf: ./run shaders/
09:35 karolherbst: k
09:35 mupuf: this is what I run
09:35 karolherbst: it would be really awesome if you would add our private repository as well
09:35 karolherbst: runs are like 10 times longer though
09:35 karolherbst: but you catch real world issues this way
09:35 mupuf: well, I do not run shaderdb on our CI at all right now
09:36 karolherbst: ahh, I see
09:36 mupuf: yes, that sounds like a good idea
09:36 mupuf: right now, hte only CI I have is the initial run of piglit on 1.5 years of data
09:36 mupuf: to catch issues
09:36 karolherbst: k
09:36 mupuf: the bloody thing has been running for a week because it takes 40 minutes to compile one version of mesa and run piglit on it
09:36 karolherbst: crazy
09:37 mupuf: well, it seems to be stuck in a loop now
09:37 karolherbst: I am sure mesa gets too many commits so that thing won't be able to keep up anyway :p
09:37 mupuf: some tests sometimes return results and sometimes don't
09:37 mupuf: it is not testing every commit
09:37 mupuf: it is bisectring only when there is a change
09:39 karolherbst: kenneth messed up?... odd
09:40 karolherbst: his IRC nick was kayden, right?
09:40 mupuf: right, but before reporting anything, remember that this is the first run
09:40 mupuf: no idea about how reliable the data is
09:40 mupuf: it at least got replicated multiple times by the tool
09:40 karolherbst: no, not related to yours
09:41 karolherbst: one of his patches breaks a shadow warrior shader in nouveau
09:41 mupuf: ah, link please? :)
09:42 mupuf: karolherbst: would be nice if you could start making traces of games, with just a few frames (one frame per scene, for example)
09:42 karolherbst: shadow_warrior/8964.shader_test is the shader
09:42 karolherbst: mupuf: yeah I know :/
09:42 mupuf: this way, we could check the rendering
09:42 karolherbst: well, usually I keep al traces with rendering issues
09:42 karolherbst: *all
09:42 mupuf: yeah, they make good test cases
09:44 karolherbst: odd
09:44 karolherbst: that patch shouldn't cause RA to fail at all...
09:46 karolherbst: wow
09:46 karolherbst: ...
09:47 karolherbst: https://gist.github.com/karolherbst/27ef7ae628461f29697f7b32879747c8
09:47 karolherbst: such a small difference
09:47 karolherbst: and spilling just fails
09:47 karolherbst: 75: is the first diff
09:49 karolherbst: crazy thing is, it shouldn't spill... at all
09:53 karolherbst: huh, only kepler1 is broken too
09:53 karolherbst: spilling still fails
09:53 karolherbst: on fermi that is
09:54 karolherbst: huh, this is just wrong
09:54 karolherbst: gpr count is like 17
09:55 karolherbst: ohhh
09:55 karolherbst: :O
09:55 karolherbst: "136: mov u32 $r1073741823 $r7 (8)"
09:55 karolherbst: the heck
09:55 karolherbst: this sounds... wrong?
09:55 karolherbst: "139: export b128 # o[0x20] %r626q (8)"
09:55 karolherbst: result of the failed spill though
09:55 karolherbst: for no reason at all
10:01 hermier: karolherbst: is there some dor for the ISA ? that smells a lot like a constant overflow'ing the generated instruction code
10:01 hermier: doc
10:01 karolherbst: well, there is none
10:01 karolherbst: except the source of envydis and mesa
10:13 hermier: karolherbst: do you have the hexa decimal of the instruction of line 136 ?
10:27 karolherbst: hermier: huh? This is still before the emit
10:28 hermier: oki
10:53 Hussam: karolherbst: https://bugzilla.kernel.org/show_bug.cgi?id=47931 that laptop is an intel graphics.
10:54 Hussam: but same issue as me when using nouveau.
10:59 Hussam: there is a patch. I will try it with both NVIDIA official driver (to make sure nothing regresses) and on nouveau (to check if it fixes anything).
15:46 imirkin_: ajax: anything that comes to mind wrt https://bugs.freedesktop.org/show_bug.cgi?id=98030 ? (xorg 1.19-related issue)
15:48 RSpliet: imirkin_: does VDPAU still work when using modesetting?
15:49 imirkin_: dont see why not
15:49 imirkin_: just a regular DRI client like any other
15:53 RSpliet: imirkin_: there's something floating in my mind about vdpau issues with... something. Could have been DRI3...? too vague in my mind to remember any specifics
15:54 imirkin_: with mesa 12.0 and newer ;)
15:54 imirkin_: where if you flip the OSD on
15:54 imirkin_: it goes to shit
15:54 imirkin_: this is not connected to Xorg versions
15:54 RSpliet: hah, okay, well that's good to know
15:56 tobijk: imirkin_: RSpliet: there was a bug with the kernel starting with 4.6 and DRI3, it got resoled now with 4.8.0
15:56 imirkin_: what kind of bug?
15:57 tobijk: it killed DRI3 apps
15:57 imirkin_: first i'm hearing about it
15:57 RSpliet: tobijk: have a reference for that bug?
15:57 imirkin_: i'm on v4.7 and dri3 works fine for me
15:57 tobijk: RSpliet: reverting a commit fixed it
15:57 tobijk: and its upstream now
15:57 orbea: dri3 works fine here too except fora few games
15:57 tobijk: sec, will find it
15:58 imirkin_: are you talking about the "cpu_coherent" thing?
15:58 orbea: eduke32, arx libertatis and openmw
15:58 tobijk: yep
15:58 imirkin_: that only affected a handful of people, and i highly doubt it was dri3-specific
15:59 imirkin_: although i could believe that using dri3 made it easier to trigger the issue
15:59 orbea: yea, at the least it doesn;t really ahppen with dri2 for those programs
15:59 tobijk: heh, i triggered it with any of my dri3 clients
16:00 tobijk: anyway its upstream now: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aaee1d1e2d97e3cb99cf0e096d2172237d762e4e
16:05 tobijk: imirkin_: did you have a time to think about insnCanLoad() already? i don't know what the right approch there would be...karols one seems to be not the right one :/
16:05 imirkin_: no, i haven't thought too much about it
16:05 imirkin_: [or at all, tbh]
16:05 imirkin_: however i know what the _wrong_ approach is - and that's futzing with the constant folding logic :)
16:05 imirkin_: [at least for MAD]
16:06 Hussam: imirkin_: hi. I stumbled onto something interesting today https://bugzilla.kernel.org/show_bug.cgi?id=47931
16:13 karolherbst: imirkin_: saw my comment about the broken shadow warrior shader regression?
16:14 imirkin_: iirc it was already broken
16:14 imirkin_: due to a RA issue
16:14 karolherbst: nope
16:14 imirkin_: although RA didn't fail
16:14 karolherbst: it worked before
16:14 imirkin_: it just messed up
16:14 karolherbst: I found the commit breaking it
16:14 imirkin_: really? have you tested it before that commit?
16:14 karolherbst: yes
16:14 imirkin_: [hint: it's broken]
16:14 karolherbst: I could play the game
16:14 imirkin_: https://bugs.freedesktop.org/show_bug.cgi?id=91895
16:15 karolherbst: didn't mean this
16:15 karolherbst: b04ef3c08a288a5857349c9e582ee2718fa562f7
16:15 karolherbst: https://gist.github.com/karolherbst/27ef7ae628461f29697f7b32879747c8
16:15 karolherbst: good is before that commit
16:15 imirkin_: yeah, but what i'm saying is ... it was already broken.
16:15 karolherbst: bad is after
16:15 karolherbst: well, check out the tgsi
16:15 karolherbst: and tell me, that it is expected to break
16:15 karolherbst: I don't see why one of them is fine, the other is not
16:15 imirkin_: it is expected to break :p
16:16 imirkin_: or rather, it's not unexpected that it breaks.
16:16 karolherbst: check out the difference in the TGSI
16:16 imirkin_: er hm, i take that back
16:16 imirkin_: all the divisions are by an immediate
16:16 imirkin_: which should be handled without a CALL
16:17 imirkin_: as are all the MODs, but we might mess something up with those... hm
16:17 karolherbst: which isn't the issue
16:17 imirkin_: isn't it?
16:17 karolherbst: 75:+
16:17 karolherbst: diff both things
16:17 karolherbst: and it will be obvious
16:17 imirkin_: heh
16:17 imirkin_: that's just like how the issue comes out
16:17 karolherbst: as I said: I don't see why the one is good the other is bad
16:17 imirkin_: but the actual issue is that we mess up RA around calls
16:18 karolherbst: ohh k
16:18 imirkin_: i haven't analyzed this particular shader
16:18 imirkin_: but i have analyzed the shader from the bug
16:18 karolherbst: k
16:18 imirkin_: and i'm moderately sure that the issues are identical
16:18 karolherbst: anyway, one "little" change wihtin glsl just made the one shader crash nouveau
16:19 karolherbst: and before that it didn't
16:19 imirkin_: wtvr
16:19 imirkin_: it's a nouveau issue
16:19 karolherbst: sure
16:19 imirkin_: not a glsl compiler issue
16:19 imirkin_: and it's the same one as in the bug i just referenced
16:19 imirkin_: unless you analyze that one and decide otherwise
16:19 imirkin_: then i'll investigate in more detail
16:19 karolherbst: k. maybe the diff helps though finding the cause of that or something
16:19 karolherbst: no clue though
16:19 imirkin_: no
16:20 imirkin_: it has to do with how RA handles fixed registers
16:20 karolherbst: ohhhhhh
16:20 karolherbst: yeah
16:20 karolherbst: that makes sense
16:20 imirkin_: and with call's you end up with fixed registers
16:20 imirkin_: of course the joke is that none of that should be necessary
16:20 imirkin_: since this is all division/mod by immediate
16:20 imirkin_: for which we have special lowering
16:20 karolherbst: funny is
16:20 karolherbst: it only fails on kepler1 with a crash
16:21 imirkin_: fermi as well, i'd imagine
16:21 karolherbst: nope
16:21 karolherbst: doesn't crash
16:21 imirkin_: odd.
16:21 karolherbst: just generates bullshit
16:21 imirkin_: is there a texture situation?
16:21 karolherbst: "136: mov u32 $r1073741823 $r7 (8)"
16:21 imirkin_: if so, that could tickle RA to come out slightly different
16:21 imirkin_: yeah, that's expected
16:21 karolherbst: but it doesn't crash
16:21 imirkin_: that's a "RA failed" issue
16:21 karolherbst: yeah, I figured
16:21 karolherbst: the "ERROR: no viable spill candidates left" already told me so
16:21 imirkin_: it leaves something uninitialized somewhere
16:21 karolherbst: kepler2 is fine though
16:22 imirkin_: yeah, coz it has more registers
16:22 karolherbst: well
16:22 karolherbst: the shader uses like 20 gprs
16:22 imirkin_: irrelevant.
16:22 karolherbst: how is it important that kepler2 has more regs then?
16:22 imirkin_: [ok, mildly relevant]
16:22 imirkin_: actually it's important that it has a different number of regs :)
16:22 karolherbst: :D
16:24 karolherbst: it would be nice to fix that issue, cause a crash ain't good
16:24 karolherbst: I could try to catch the uninitiialized thing though+
16:26 karolherbst: mhh, memcheck seems happy though
16:26 karolherbst: ohh, most likely stack stuff
16:26 imirkin_: iirc it's explicitly initialized to that value
16:26 karolherbst: wait
16:26 karolherbst: valgrind should catch this
16:26 karolherbst: uhhh. k
16:26 imirkin_: hex(1073741823)
16:26 imirkin_: '0x3fffffff'
16:27 imirkin_: with a mask, that's -1
16:27 imirkin_: iirc it's -1, and then gets shifted by 2
16:27 karolherbst: k, makes sense
16:27 karolherbst: I guess that is RA just aborting
16:27 imirkin_: yes.
16:28 karolherbst: and now I know why kepler1 crashes
16:28 imirkin_: ideally we'd handle RA failures a little better - e.g. use some cooked shader that just does something dumb
16:28 karolherbst: it crashes within the sched calculation
16:28 imirkin_: makes sense.
16:29 karolherbst: score->rd.r is garbage
16:29 karolherbst: ohh wait no
16:29 karolherbst: that is the index being bs again
16:29 karolherbst: ohh right, I know that one
16:30 karolherbst: "v->reg.data.id" contains crap and then with that value an array is accessed
16:42 karolherbst: imirkin_: shouldn't "gcra.allocateRegisters" return false if anything fails?
16:42 imirkin_: dont remember
16:42 karolherbst: well, it even prints an "ERROR"
16:42 imirkin_: like i said, i don't remember.
16:43 karolherbst: I am not asking what it does, just if it should return false or true in this case, cause I would just return false if anything bad goes wrong
16:43 imirkin_: check its callers? dunno.
16:43 karolherbst: well, I would say we should return false and fix the callers then
16:44 imirkin_: wtvr
16:44 tobijk: it at least sometimes returns false if something goes wrong
16:45 tobijk: so i guess it is intended to :>
16:47 karolherbst: nice, much better now
16:48 karolherbst: now it fails nicely
16:49 karolherbst: imirkin_: does this look fine to you? https://github.com/karolherbst/mesa/commit/363fd15d8feea8037023d4acc526d0aa3929a8b6
16:51 tobijk: karolherbst: looks fine, as it follows what is already done for coalesce
16:51 imirkin_: seems reasonable.
16:51 tobijk: how does it fail now btw?
16:52 karolherbst: it tries to do RA three times
16:52 karolherbst: and then aborts
16:52 imirkin_: the idea is that it tries to spill
16:52 karolherbst: nv50_ir_generate_code: ret = -4 ... Error compiling program: -4
16:52 imirkin_: ideally after the first time spilling it can RA, but sometimes it's imperfect
16:52 karolherbst: yeah, there was a comment
16:52 imirkin_: so there could be a 2nd fail
16:52 karolherbst: "// TODO: need to fix up spill slot usage ranges to support > 1 retry"
16:53 imirkin_: by the third try, you're doing something super-wrong
16:53 imirkin_: yeah, there's some amount of questionable stuff
16:53 karolherbst: yeah, but a clean abort is better than a hard crash later
16:53 karolherbst: I think we fixed some RA > 1 retry issues already, but I guess there are more
16:54 karolherbst: imirkin_: should I send nouveau related mesa patches also to the nouveau ML or just mesa-dev?
16:55 imirkin_: wtvr
16:55 karolherbst: k
16:55 karolherbst: then I am lazy :D
16:59 tobijk: karolherbst: rb for the patch :)
16:59 karolherbst: already sent out
17:01 tobijk: np, imirkin rb'd it too, so its irrelevant anyway :D
17:01 karolherbst: imirkin_: the compile segfaulted
17:01 karolherbst: for real
17:02 karolherbst: it basically does somearray[0x3fffffff] or something like that
17:03 karolherbst: ohh you mean with the fix
17:03 karolherbst: uhh, sure, the shader isn't compiled, so I guess that still messes up the game somewhat
17:04 karolherbst: but in the end, the draw call will just fail, but the game won't segfault
17:05 imirkin_: well, i'm pretty sure there are some asserts in places
17:05 imirkin_: to make sure there's a shader
17:05 karolherbst: yeah, but asserts don't get triggered on release builds. right?
17:06 karolherbst: anyway, a game missrendering is still better than a crashing game
17:07 karolherbst: well, I will just try it out
17:07 karolherbst: maybe I hit that shader
17:12 karolherbst: mhh, as it seems I don't
17:16 karolherbst: imirkin_: well, the black gun issue is fixed anyway
17:19 tobijk: karolherbst: maybe its a shader for that "black gun" some lighting effect i could imagine :>
17:44 karolherbst: tobijk: it is completly unrelated
17:44 karolherbst: just a random shader crashed
17:44 karolherbst: no clue what it is
17:54 hermier: imirkin_: my issue sounds to be an initialisation issue
17:55 hermier: imirkin_: yesterday I rebooted to nouveau from nvidia, and the problems were not visible (or I was not able to reproduce them)
17:55 hermier: imirkin_: so I'll try again this night form a cold boot
18:25 karolherbst: small update regarding the documentation for REing: https://gist.github.com/karolherbst/4341e3c33b85640eaaa56ff69a094713
18:25 karolherbst: I added titles for everything I would like to add there
18:25 karolherbst: I think that's all so far, but maybe I missed something
18:33 ajax: imirkin_: that's a weird bug. really not sure what would cause that.
18:34 ajax: it's not like exa changed at all in 1.19
18:34 imirkin_: ajax: ok, glad to hear i'm not alone.
18:34 imirkin_: well, this is likely xvideo-related?
18:35 imirkin_: which i'm guessing is also not a hotbed of innovation
18:35 ajax: yeah, nothing going on there either
18:35 ajax: i mean, both were changed to the new blockhandler interface?
18:36 ajax: and that might be called at a slightly different time than before, but still as often.
18:37 imirkin_: so we used to have
18:37 imirkin_: RegisterBlockAndWakeupHandlers((BlockHandlerProcPtr)NoopDDA,
18:37 imirkin_: and now we have SetNotifyFd(drmmode->fd, drmmode_notify_fd, X_NOTIFY_READ, scrn);
18:37 imirkin_: i haven't the faintest clue what the old *or* new things do
18:39 ajax: ugh
18:42 imirkin_: notice an issue? or general frustration with my lack of knowledge of how X things work?
18:42 ajax: :q
18:42 ajax: guh
18:44 ajax: sorry, was re-reading the new poll code
18:44 ajax: the old wakeup handler and the new fd notify are both meant to do the same thing
18:45 ajax: when the server 'wakes up', ie poll() returns readable fds, call the appropriate callback
18:45 imirkin_: right, so just a regular socket event dispatch loop
18:46 imirkin_: i'm mostly looking at the "NoopDDA" thing, although i guess that's for "block"? not sure what that is.
18:46 ajax: expands to "doesn't do anything"
18:46 imirkin_: [i.e. when you get a EAGAIN from the socket?]
18:46 ajax: it's just a {} function
18:46 imirkin_: right, i assumed that...
18:46 imirkin_: but when does it get called?
18:46 ajax: and BlockHandler is the callbacks called immediately _before_ you go into select
18:47 imirkin_: ahh
18:47 ajax: was always a bit stupid that you had to provide both if you provide either
18:50 ajax: yeah, it really does look like things should get called when and as often as they did before
18:50 imirkin_: anyways... the classy thing would be for someone to install xorg 1.19 and have a look at wtf is going on
18:51 ajax: so, either i'm wrong in my reading, or that's not the problem.
18:51 imirkin_:just updated to xorg 1.18
19:13 tobijk: imirkin_: so whats the problem with 1.19 exactly? i have a 1.19rc stack ready
19:13 imirkin_: check the bug i referenced above
19:13 imirkin_: https://bugs.freedesktop.org/show_bug.cgi?id=98030
19:14 tobijk: ah thx
19:14 tobijk: ah that one
19:15 tobijk: well lets see if i have stuttering with my ancient nv86 :)
20:45 tobijk: imirkin_: concerning that bug: i can repro it and it stutters epically (as long as i do not move the mouse, if i do everything is fine, so we seem to miss drawing events)
20:46 imirkin_: ajax: sounds like it's not getting called quite as often ;)
20:46 ajax: well.
20:47 tobijk: i'm going to downgrade, just to make sure it is really the same bug
20:55 tobijk: imirkin_: ajax: yep its 1.19rc and nouveau
20:55 tobijk: btw happens with totem, mpv and vlc
20:55 imirkin_: what about mplayer?
20:55 imirkin_: i.e. is this GL or Xv?
20:57 tobijk: let me fist check something corresponding kde...i saw there redrawing errors as well
20:58 tobijk: yep same problem
21:01 imirkin_: can you switch to a simpler environment
21:01 imirkin_: and run, e.g., glxgears?
21:01 imirkin_: and then, separately, mplayer -vo xv <somevideo>
21:10 tobijk: imirkin_: playback with xv is fine, glxgears is stuttering though (unless moving the mouse again)
21:12 imirkin_: ok, so it's some DRI issue then? and totem/mpv, in their infinite genius, use GL?
21:13 tobijk: well i can force mpv to xv as well ;-) but they default to GL, yeah
21:14 imirkin_: sure.
21:14 imirkin_: ok, so xv = good, GL = bad?
21:14 tobijk: yep
21:14 tobijk: DRI2 backend
21:15 imirkin_: can you see if DRI2 and DRI3 are different?
21:15 tobijk: how was the dri3 enable again? :D
21:25 orbea: tobijk: something like this in /etc/X11/xorg.conf.d/nouveau-dri3.conf http://dpaste.com/3P11K42
21:26 tobijk: yeah have it already
21:27 tobijk: imirkin_: DRI3 is fine with xv and GL
21:27 tobijk: DRI2 backend is the problem here
21:27 imirkin_: and to confirm, when you have dri3 enabled
21:27 imirkin_: and you run LIBGL_DRI3_DISABLE=1 glxgears
21:28 imirkin_: you get the problem
21:28 imirkin_: but without the env var, you don't?
21:28 tobijk: yep
21:28 tobijk: and yep
21:28 imirkin_: awesome
21:29 tobijk: 60 vs 2 fps ;-)
21:29 imirkin_: i'll note that in the bug
21:29 orbea: 2 fps...ouch
21:30 tobijk: orbea: when i move the mouse its ok again, the bug is all about forgetting to draw
21:30 orbea: ah
21:30 imirkin_: tobijk: if it's not too much trouble, can you repeat the experiment with the modesetting ddx?
21:31 imirkin_: i.e. whether dri2 is broken there as well
21:31 tobijk: imirkin_: np
21:31 imirkin_: or if this is some issue that's more specific to the nouveau ddx
21:31 imirkin_: (i kinda assume the latter, but who knows)
21:31 imirkin_: (sure would love to be able to blame this on ajax...)
21:31 orbea: heh
21:35 tobijk: imirkin_: its nouveau
21:36 imirkin_: tobijk: ok, so it's all good on modesetting?
21:36 imirkin_: with both dri2 and dri3?
21:36 tobijk: oh no wait
21:36 tobijk: modesetting did not report dri activation, but it is using it
21:36 imirkin_: modesetting always does dri3 iirc
21:36 tobijk: LIBGL_DRI3_DISABLE=1 glxgears is lagging as well
21:37 imirkin_: aha!
21:37 imirkin_: thanks
21:37 imirkin_: ajax: --^
22:08 karolherbst: hakzsam: that "GCRA::simplify" method is just plain ugly anyway
22:10 hakzsam: yep, as I said, your call :)
22:11 karolherbst: I could clean that mess up, sadly simplifyEdge indeed touches lo...
22:11 karolherbst: but those ifs aren't really necesary
22:12 hakzsam: I didn't look closely at the method though
22:14 karolherbst: at least shader-db is now happy
22:14 karolherbst: allthough we have many shaders failing :/
22:15 hakzsam: many? I only have few, like 5 or so
22:15 hakzsam: and I use a special piglit branch for handling that
22:16 karolherbst: well
22:16 hakzsam: but all shaders from our repo don't fail here
22:16 karolherbst: 5 are many compared to 0
22:16 hakzsam: yeah, but 5 regarding 30k :)
22:16 karolherbst: mhh
22:16 karolherbst: doesn't a shadow warior shader fail for you now?
22:16 hakzsam: since when?
22:16 karolherbst: since b04ef3c08a288a5857349c9e582ee2718fa562f7
22:17 hakzsam: I guess I ran shaderdb before that commit
22:19 karolherbst: mhh, maybe I modifies simplify for the worse...
22:20 karolherbst: mhh
22:20 karolherbst: more fails
22:21 karolherbst: but: https://gist.github.com/karolherbst/d693b73170b42adc8db1b4c9078d5c6a
22:21 karolherbst: I guess shader-db doesn't handle that right
22:22 karolherbst: we really should fix RA to not fail for silly reasons...
22:24 tobijk: oh what did you change? :>
22:24 karolherbst: silly things
22:24 karolherbst: just made RA do randomly ordered things in another random order
22:25 tobijk: uhm...
22:25 karolherbst: the runner crashed as well
23:14 ajax: imirkin_: huh, so dri2 regression then