05:33 robink: MrCooper, everyone-else: I think I sorted the issue w/ clover & libclangCodeGen.so. src/gallium/targets/opencl/meson.build is looking for libClangCodeGen plus a bunch of other Clang-related module libraries. They seem to all be folded into libclang.so and libclang-cpp.so now, so I just replaced the long set of clang* library dependencies with the aforementioned pair. Mesa compiles/builds (w/ OpenCL support!) without issue with that tweak.
06:29 tomeu: robink: have a patch I could look at?
07:25 daniels: robink: i think that's only true if you do a shared-only build, which is also not supported upstream
08:02 mischief: i seem to have a memory leak somewhere but i am not sure how to find it. it only seems to happen when i run games under wine with dxvk. even if i terminate X the memory is not freed. nothing stands out in top or slabtop.. anyone know how i can debug this further?
08:14 MrCooper: mischief: kmemleak?
08:24 robink: tomeu: I do, one sec (but note that it only has been tested on my system/build-config (which, according to daniels, is not officially supported), might be Doing It Wrong even if it works elsewhere, isn't guaranteed to not set your house on fire, etc).
08:28 robink: tomeu: https://gist.github.com/Haifen/746bef276ad1f08c905e52e9a0186946
08:30 MrCooper: yeah, it's wrong :) it's working out of the box for me and in general
08:31 MrCooper: i.e. this is a workaround for something specific to your setup
08:33 MrCooper: hmm, or maybe it's just picking up the static libraries here?
08:36 MrCooper: robink: make sure you don't enable BUILD_SHARED_LIBS in the LLVM build
08:37 MrCooper: (enable LLVM_BUILD_LLVM_DYLIB instead)
08:42 robink: MrCooper: Gotcha, lemme check what was enabled for LLVM/Clang.
08:45 robink: MrCooper: Looks like that was the case (-DBUILD_SHARED_LIBS=OFF, -DLLVM_BUILD_LLVM_DYLIB=ON).
08:45 MrCooper: that said, it might be nice to link the big shared clang libraries when available, but as is this patch would likely break some working setups (e.g. static-only LLVM/clang builds)
08:46 robink: MrCooper: Indeed, I'm not pushing this anywhere upstream, I'm using it since it works for me, and IIRC Gentoo defaults to shared-only builds of LLVM/Clang.
08:46 robink: MrCooper: Gentoo will have to figure something out for Mesa going forward, most likely.
08:47 robink: MrCooper: -DBUILD_SHARED_LIBS is off for Clang, as well.
08:47 MrCooper: good to see Gentoo isn't enabling BUILD_SHARED_LIBS anymore at least
08:48 robink: MrCooper: I s'pose. This is an #llvm question, but do you know if it's possible to get Clang to build the broken-out shared libraries as it used to?
08:48 MrCooper: sounds like you mean BUILD_SHARED_LIBS, but it's a bad idea for various reasons
08:57 robink: MrCooper: Ah, OK
08:58 robink: MrCooper: OK, well I'll keep tooling along with what I've got going on my system, and will wait to see what upstream Gentoo does for Mesa linked non-statically against LLVM/Clang.
08:59 MrCooper: ideal would be an upstream Mesa change to link the big shared libraries when available and the individual ones otherwise
09:01 robink: MrCooper: Hm, I'm still not familiar enough with Meson to set up an if/then dependency search right this second, but I'll be thinking about it.
09:03 robink: MrCooper: I'd be happy for the Mesa codebase change to live as a Gentoo patch for a while, but I'm slightly interested in getting something folded into the Portage tree so that others trying to do what I'm doing (link Mesa against Clang built with -DBUILD_SHARED_LIBS=OFF, which is the default (for versions 10 & 11)) don't run into similar troubles.
09:42 andrzej_p: danvet: It's after the New Year now. Do you think you can have some time to have a look at https://patchwork.kernel.org/cover/11297799/ (AFBC series)?
09:46 danvet: andrzej_p, I think I chatted with daniels and figured I'll offload this to someone at collabora :-)
09:47 danvet: also just arrived from my lca trip, so not having a working brain right now anyway ...
09:51 mischief: MrCooper: actually i have kmemleak on
09:51 mischief: it also reported nothing
09:51 mischief: :)
09:53 MrCooper: how do you know there's a leak?
09:54 mischief: i dont really know anything about graphics programming and im out of ideas, thats why i came here. i'm using amdgpu on a raven ridge chip btw
09:55 MrCooper: what are the symptoms?
09:57 mischief: MrCooper: active memory use never goes down even if i stop most programs (eg systemctl rescue)
09:57 mischief: and my system will oom if i keep playing games
09:58 mischief: even if i stop and start the game again
10:10 swivel: mischief: are you using X or Wayland?
10:14 mischief: swivel: X
10:19 swivel: mischief: and you don't see the Xorg's vsiz accounting for the memory use?
10:22 mischief: i wasn't really looking at virtual size, just active/resident memory. i have to sleep but ill follow up if it keeps happening
10:23 swivel: np, you'll prolly get more response during US business hours anyways :)
10:28 turol_: jekstrand: your anv multiple physical devices patch broke radv
10:28 turol_: it now fails to enumerate my gpu (pitcairn)
10:28 turol_: but probably also ALL radv devices...
10:31 bnieuwenhuizen: turol_: what patch?
10:31 turol_: bnieuwenhuizen "anv: Allow enumerating multiple physical devices"
10:32 turol_: 34c8621c3
10:34 bnieuwenhuizen: turol_: can you try removing (temporarily) the anv json file?
10:34 turol_: as soon as i figure where install puts it...
10:34 bnieuwenhuizen: since it does not change radv I suspect anv just blows up with 0 intel devices
10:34 bnieuwenhuizen: /usr/share/vulkan/icd.d/ ?
10:35 bnieuwenhuizen: alternatively ~/.local/share/vulkan IIRC if installed for an user
10:36 turol_: only had intel_icd.i686.json in there
10:36 turol_: moving it did not help
10:36 turol_: probably not the right file
10:36 turol_: what is the correct command to configure mesa to not build anv?
10:37 bnieuwenhuizen: meson configure -Dvulkan-drivers=amd IIRC
10:37 turol_: ok, found .x86_64.json in /usr/local/share/vulkan/icd.d
10:37 turol_: moving that fixed it
10:40 bnieuwenhuizen: turol_: can you file a bug in gitlab.freedesktop.org/mesa/mesa/issues?
10:41 turol_: i'm not set up on the new gitlab yet
10:41 turol_: so not easily just now
10:43 bnieuwenhuizen: turol_: is it ok to paste this conversation in a bug?
10:43 turol_: yes
10:44 bnieuwenhuizen: https://gitlab.freedesktop.org/mesa/mesa/issues/2386
10:44 gitbot: Mesa issue 2386 in mesa "anv: Regression causing issues for radv when there are no Intel devices" [Anv, Regression, Opened]
10:44 MrCooper: turol_: GitLab supports logging in with credentials from several other services
10:45 turol_: yes but in addition to that it requires figuring out cookie and javascript whitelists
10:45 turol_: and for my use case right now it's enough to work around this by disabling anv
10:54 MrCooper: turol_: doesn't require any 3rd-party javascript or cookies for me
11:31 alwyn: hola
11:31 alwyn: I guess the info to report a bug as described here should be updated to point to the freedesktop GitLab instead? https://github.com/torvalds/linux/blob/d96d875ef5dd372f533059a44f98e92de9cf0d42/drivers/gpu/drm/i915/i915_gpu_error.c#L1820-L1828 :)
11:32 alwyn: Maybe just re-point to gitlab.freedesktop.org/drm/intel or even gitlab.freedesktop.org/drm/intel/-/wikis
14:51 okias[m]: mareko ping, can you confirm that rXXX + radeonsi cannot be used on ARMs?
15:16 karolherbst: btw, how does that work with r-by tags and margebot? Does it add the tags automatically or is this still a manual process?
15:17 bnieuwenhuizen: manual still
15:18 bnieuwenhuizen: there is a Marge-Bot feature to do it based on MR approvers, but approvers are not in this Gitlab edition
15:19 daniels: eh? it adds them from comments
15:20 karolherbst: is there some special syntax or so? I am mainly thinking about cases where somebody only gives tags for certain commits
15:21 karolherbst: do those comments have to be on the patches? or the MR?
15:22 bnieuwenhuizen: daniels: wait what? I though it was still having the following issues? https://github.com/smarkets/marge-bot/issues/242
15:22 gitbot: smarkets issue 242 in marge-bot "reviewers stripped on gitlab CE" [Open]
15:25 daniels: bnieuwenhuizen: we don't pass the --add-reviewers flag
15:26 bnieuwenhuizen: daniels: I thought it didn't do anything with reviews without that flag (so we have to manually add them?)
15:27 daniels: no, it scrapes the tags from MR comments and adds them
15:30 daniels: e.g. https://gitlab.freedesktop.org/mesa/mesa/commit/dc594c95ddc66888e5971a8684a62b0c11ec9885 - the tags there were added by Marge from MR comments
15:32 bnieuwenhuizen: daniels: in that MR I believe Neil added it before it got assigned to Marge? https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2337/diffs?commit_id=ea77b95603e417952e86401782a6fdcb42bbe5ea
15:32 gitbot: Mesa issue (Merge request) 2337 in mesa "gitlab-ci/lava: add pipeline information in the lava job name" [Ci, Lima, Panfrost, Merged]
15:32 karolherbst: daniels: right.. but again, what happens if you give r-bys only for certain commits by "$list_of_commits are r-by: $me"
15:32 MrCooper: right, don't think Marge currently does anything with such tags
15:33 MrCooper: she just adds the Part-of and Tested-by tags, that's all
15:33 daniels: marge isn't a real human, she doesn't do NLP
15:34 karolherbst: well, that's why I was asking if there is a special syntax for it
15:35 karolherbst: but if apparently there isn't, then it's dangerous to have marge adding those tags as it can be wrong
15:35 karolherbst: or at least I don't want my r-by tags on commits I didn't review
15:35 karolherbst: but it sounds like most participating in this discussion are under the impression marge doesn't add those anyway
15:36 daniels: (apparently I can't read source code and it doesn't actually automagically add the R-b/T-b tags)
15:37 daniels: (so ignore me)
15:43 MrCooper: we should simply stop adding those tags to the commit logs, they're recorded in the MRs; that'll make merging MRs less painful, and as a bonus save some CI runs
15:48 karolherbst: I'd prefer to have them inside git
15:48 karolherbst: you know, because.. in 20 years we will migrate away from gitlab :p
15:49 karolherbst: or 10 or whatever
15:49 karolherbst: the problem is just, that with the gitlab CE version it's not easily possible to do with marge, which is what I'd rather tackle than not adding those to git :(
15:49 karolherbst: and why is that even an enterprise feature :(
15:50 karolherbst: wait.. I have an idea
15:50 daniels: MrCooper: srsly
15:51 daniels: karolherbst: well, if we lose everything then we won't have an archive of any of the discussion that led to changes, or the changes themselves
15:51 karolherbst: sure, but archiving the discussion is less work than extracting all tags
15:53 karolherbst: also.. maybe I don't want to have to go to the gitlab site and search the entire comments to see who reviewed it
15:53 karolherbst: especially if some MRs are like 100 comments big
15:55 daniels: pretty sure I already wrote something which uses the API to scrape that out and sent it to the list
15:57 karolherbst: right, but then we have the problem of some tags only valid for a subset of commits and stuff, which is parseable by a human though, but then I still need to execute some script and.. maybe even setup an gitlab API key and... you know
15:57 karolherbst: anyway, this issue can be fixed on a technical level.. I just doubt anybody has time for actually doing it :(
15:59 Venemo: any nouveau devs around here who'd be willing to mess around with GCC 10?
15:59 karolherbst: ufff
15:59 karolherbst: compiler errors?
15:59 imirkin_: Venemo: what's the issue?
15:59 Venemo: https://gitlab.freedesktop.org/mesa/mesa/issues/2385
15:59 gitbot: Mesa issue 2385 in mesa "Mesa no longer compiles with GCC 10" [Radv, Opened]
16:00 Venemo: I opened an MR to fix the new warnings in ACO, and another to fix the radeon errors
16:00 imirkin_: Venemo: it just says "nouveau has issues"
16:00 imirkin_: is there a concrete list?
16:00 Venemo: but I don't know enough about nouveau to dare to touch it
16:00 Venemo: imirkin_: I can give you a build log if that helps
16:00 karolherbst: ehhh
16:00 karolherbst: only 32 bit fails?
16:00 karolherbst: uff
16:00 Venemo: no
16:00 imirkin_: karolherbst: can't hurt =]
16:00 imirkin_: er, Venemo --^
16:00 karolherbst: Venemo: https://copr.fedorainfracloud.org/coprs/xxmitsu/mesa-and-llvm-git/build/1169261/
16:00 karolherbst: like literally
16:00 karolherbst: only rawhide 32 bit failed
16:01 Venemo: it appears that only that had gcc 10
16:01 Venemo: it fails for me locally on x86_64 too just the same
16:01 Venemo: after I manually installed gcc 10
16:01 karolherbst: okay, but it fails to build while compiling aco
16:02 Venemo: like I said I already fixed that
16:03 karolherbst: okay, so.. even in later logs there is no indication something goes wrong inside nouveau
16:03 karolherbst: or at least _what_ went wrong
16:03 Venemo: you can observe that if you compile mesa with my two MRs applied
16:04 Venemo: I can give you a log if you give me a couple of minutes
16:09 Venemo: karolherbst, imirkin_ here you go: https://paste.centos.org/view/88242a92
16:09 Venemo: there are a lot of multiple definition issues
16:09 karolherbst: ufff
16:09 Venemo: among other things
16:09 imirkin_: well that's just super-duper
16:10 Venemo: sorry I had to be the bearer of the bad news
16:10 karolherbst: add extern to the one in nvc0_resource.h?
16:10 imirkin_: i think it's just missing some extern or something else annotations
16:11 karolherbst: well, I'd would fix it, but my distribution doesn't allow me multple installations of gcc, so I would probably spend more time setting gcc-10 up then somebody else fixing it
16:11 karolherbst: *than
16:11 imirkin_: if it's packaged for gentoo, i can look at installing it tonight
16:12 imirkin_: hopefully meson can take a custom CC without too much complaining?
16:12 karolherbst: "10.0.0_pre9999"
16:12 imirkin_: let's hope it builds :)
16:12 karolherbst: :)
16:12 Venemo: I too didn't wanna break it, so I just made a Fedora 32 chroot and used that
16:12 karolherbst: but yeah.. I could install gcc on my gentoo machine as well
16:13 imirkin_: it'll take like 1-2h to build it i think =/
16:13 Venemo: adding 'extern' to "const struct u_resource_vtbl nvc0_miptree_vtbl;" seems to help
16:13 karolherbst: Venemo: right... but adding some externs should be doable by everybody. I don't think there is any more serious issues than some missing externs Venemo?
16:13 imirkin_: in another year, i can get a new computer. (i'm on a 10y upgrade cycle)
16:13 karolherbst: imirkin_: uff :D
16:13 Venemo: there remains omx which I have no idea about
16:14 karolherbst: imirkin_: make it count and get an epyc system this time :p
16:14 karolherbst: EPYC 7601
16:14 karolherbst: just to be sure
16:14 imirkin_: i tend to go for where-ever the price / performance curve bends
16:14 imirkin_: i.e. before the hockey stick :)
16:14 karolherbst: I guess a EPYC 7551P is good enough then as well :D
16:15 Venemo: guys, give me a few more minutes to see if adding that single extern fixes it or not.
16:15 imirkin_: iirc, at the time, i7-920 + 6GB RAM fit the bill
16:15 karolherbst: 9 years ago?
16:15 imirkin_: i think so... very very late 2010
16:15 karolherbst: I think even then I had 16GB RAM :D
16:15 imirkin_: or very very early 2011
16:15 imirkin_: the motherboards didn't like 4x DIMMs...
16:16 karolherbst: :/ ehh
16:16 imirkin_: and 4GB was 4x as expensive as 2GB
16:16 karolherbst: maxed RAM or the system is trash, that simple
16:16 imirkin_: (per dimm)
16:16 imirkin_: and it was quite an upgrade over the 512MB ram athlon xp 1700+ i had before...
16:16 karolherbst: yeah, that's true
16:17 imirkin_: (which itself was a cheat ... the system started out as a tbird 900)
16:17 imirkin_: ah ... the days when you actually had interchangeable cpu/motherboard combinations...
16:18 karolherbst: imirkin_: you don't today?
16:18 imirkin_: please tell me about the various CPUs that fit into a LGA-1366 socket.
16:18 imirkin_: and how many years apart they were made
16:19 imirkin_: vs the Socket A
16:19 karolherbst: mhh 1366 was there for 4 years
16:19 imirkin_: only the i7-9xx series fit into it
16:20 karolherbst: but yeah, a lot of people are complaining these days about how those sockets are only changed to sell newer mbs :p oh well
16:20 imirkin_: well, maybe not _only_, but it certainly doesn't hurt
16:20 Venemo: hm, yep, the extern was enough
16:21 karolherbst: \o/
16:21 Venemo: I still have no idea about omx
16:21 karolherbst: patch is r-by: me (if it only adds the extern)
16:22 karolherbst: but it's fun how the gcc devs find something to break in every single major and minor update :p
16:27 imirkin_: maybe it was already broken, they're only now warning abou tit?
16:27 imirkin_: sounds like having that in the declared symbols of all the .o files is really bad
16:31 karolherbst: well.. it was const
16:31 karolherbst: but still...
16:31 kisak: side effect of all these socket changes is not even trying to do any future proofing on the UEFI implementation for bootstrapping the cpu
16:32 karolherbst: imirkin_: but... if there would be multiple copies, we would have ran into weirdo segfaults.. so I think it's fine
16:32 imirkin_: well, the fact is that it's a const
16:32 imirkin_: so it doesn't matter
16:32 imirkin_: but if it weren't, and multiple .o files' functions modified it, they may have been very sad.
16:34 Venemo: there are a few warnings in GCC 10 that simply don't make any sense
16:34 Venemo: so could be a bug in GCC itself...
16:34 Venemo: karolherbst: can you add your r-b here? https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3490
16:34 gitbot: Mesa issue (Merge request) 3490 in mesa "nouveau/nvc0: add extern keyword to nvc0_miptree_vtbl." [Nouveau, Opened]
16:35 karolherbst: Venemo: my hope was you add it before pushing though
16:35 imirkin_: that's weird though. it should be treated like a forward-declaration
16:35 imirkin_: if it were c++, then there'd be a default constructor and such, but i thought in C, that would not declare storage.
16:35 karolherbst: pro tip: 1. click on commits 2. add a comment, not the other way around :p
16:35 Venemo: what do you mean?
16:36 karolherbst: nothing
16:37 imirkin_: he means "note to future-self"
16:37 karolherbst: ;)
16:37 Venemo: karolherbst: I added your r-b now. hope that's ok
16:37 karolherbst: I guess clicking on changes is faster
16:38 karolherbst: Venemo: sure, otherwise I wouldn't have given you permission twice :p
16:38 Venemo: ok, thx
18:39 imirkin_: anholt: not _completely_ arbitrarily, for ssbo vs atomics -- added atomics support first :)
21:35 anholt_: jekstrand: flto has been trying to get struct varyings working and has https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3109/diffs?commit_id=85cf19c68094c3e7b163b1e0a6a3ee41f7b1f3e2 -- does this look reasonable to you? I'm comparing it to intel and intel seems to keep struct varyings around, but I can't quite figure out how they actually work.
21:35 gitbot: Mesa issue (Merge request) 3109 in mesa "turnip: varying fixes" [Freedreno, Turnip, Opened]
21:38 Kayden: that looks pretty crazy to me but I've unfortunately forgotten how this stuff actually works
21:41 Kayden: seems like they get split in most test cases :(
21:41 anholt_: it definitely seems wrong to me to have this struct walk be in the driver instead of having been split up by some core nir thing.
21:44 Kayden: yeah...I wouldn't think you'd need to do that
21:44 jekstrand: anholt_: For SPIR-V, we split if and only if it's an interface block.
21:44 jekstrand: anholt_: And the reason is XFB
21:44 anholt_: xfb
21:44 anholt_: /o\
21:44 jekstrand: For interface blocks, we have to split in order to apply per-member locations
21:45 jekstrand: For anything deeper, if we split, we can't gather XFB info
21:45 jekstrand: We could probably come up with a way to do it but it would require replicating more data and making splitting XFB-aware. /o\
21:47 jekstrand: After XFB info has been gathered, you could probably have a NIR pass which splits
21:47 jekstrand: Though you have to be careful with that if you have indirect array accesses that you want to not have as if ladders
21:52 anholt_: jekstrand: so it sounds like to be future-looking, we really need to handle struct input variable types in our backend?
21:53 anholt_: (right now it does a glsl_get_components() assuming things have been split)
21:54 jekstrand: Yeah
21:54 jekstrand: sadly
22:34 anarsoul: anholt_: any ideas what could be wrong with kmsro with 32-bit mesa and 64-bit kernel?
22:37 anholt_: anarsoul: sounds unlikely
22:38 anarsoul: I'm looking into lima cmd stream dumps from https://gitlab.freedesktop.org/lima/mesa/issues/127
22:38 gitbot: Lima issue 127 in mesa "Lima fails with white screen in master. 19.1 is ok" [Opened]
22:38 anarsoul: and looks like stream is totally fine, irq nums for job completing are increasing in /proc/interrupts
22:39 anholt_: is your command stream identical to a working environment?
22:40 anarsoul: anholt_: I haven't checked it yet. I'll try to reproduce it myself tonight
22:40 anarsoul: yet according to the dump lima thinks that it's working just fine
22:41 anholt_: I mean, it's bisected to a pretty major change, and the argument against that change being the culprit seems to be "but it works for other stuff"?
22:42 anholt_: I'm not seeing how kmsro is implicated
22:43 anarsoul: anholt_: that's benign change that doesn't affect kmscube shaders
22:43 anarsoul: also it works fine with 32-bit userspace and 32-bit kernel, so there must be something with kernel interaction
22:43 anholt_: the reporter claims to have bisected, why do you distrust the bisect that landed on a commit in your driver?
22:44 anholt_: is it because you looked at the shaders on your local environment?
22:45 anarsoul: anholt_: the shader is the same as in working environment. Also kmscube shaders don't have integers
22:46 anholt_: I don't see the reporter saying that they swapped just the kernel for 32 and got it working. where's that?
22:46 anarsoul: anholt_: lima is working on H3 in CI (although it's disabled atm for different issues) and it's 32-bit board
22:48 anholt_: so, wait, different HW, with a different software payload than the reporter?
22:48 anarsoul: anyway, I'll try to reproduce it myself and come back
22:48 anarsoul: anholt_: the same HW works fine with 64-bit userspace
22:48 anholt_: did the reporter say that?
22:49 anarsoul: yes, not in this bug report though. It's Allwinner A64-based device (pinephone in this case)
22:49 anarsoul: that's my main development platform
22:50 anarsoul: (A64, not pinephone)
22:51 anholt_: I would definitely recommend that you get exactly that reporter's software stack and incrementally replace with yours.
22:53 anarsoul: anholt_: that could be tricky
22:54 anholt_: trying to deduce a bug from "what part of my codebase might be broken?" is even trickier.
22:59 anarsoul: anholt_: it depends on how exotic is reporter's sw stack :)
22:59 anarsoul: I'll try to reproduce it myself first, if it works on my side I'll instrument lima to dump images from BO that it uses as color buffer
23:08 mattst88: https://gitlab.freedesktop.org/mattst88/mesa/-/jobs/1415946
23:09 mattst88: my CI build failed because spec/ext_timer_query/time-elapsed unexpectedly... passed? failed? not sure
23:10 imirkin_: unexpectedly passed, from the looks of it
23:10 imirkin_: stop fixing tests!
23:10 mattst88: given that spec/ext_timer_query/time-elapsed is not a consistent test...
23:10 mattst88: (1) what should I do to get Marge to take my code? and
23:10 mattst88: (2) can we stop running spec/ext_timer_query/time-elapsed so this doesn't happen in the future?
23:10 anholt_: if we don't expect that test to be stable in CI, then we should add it to the skip list
23:10 mattst88: cool
23:11 mattst88: looks like I just need to modify piglit/quick_gl.txt ?
23:12 mattst88: or quick_gl.txt.baseline
23:12 anholt_: that's the expected result
23:12 anholt_: .gitlab-ci.yml for the explicitly skipped tests
23:13 mattst88: okay, thank you
23:13 anholt_: (I think it will also mean you need to add the skip mention to the baseline, so that we expect it to be skipped.)
23:14 anholt_: (I tend to run a CI pipeline with the skip added for a piglit and see what happens)
23:15 mattst88: huh, I see DEQP_SKIPS which gets passed to --exclude-list but not a piglit skip list
23:17 anholt_: look for "-x"
23:19 mattst88: ah, of course. thanks!