00:50 anholt_: I've got a rebased nir-to-tgsi compiling, if anyone's interested in that branch. was thinking about it again after having to trace through tgsi paths of mesa/st and wanting to just delete them
00:53 alyssa: nir-to-tgsi, huh?
00:54 HdkR: For those few things that still rely on TGSI and won't be moving to NIR for a while :)
00:58 alyssa: Gah, well, now it's not faulting, it's just rendering completely and utterly wrong
01:00 alyssa: If I disable blending it's ok but I really shouldn't have to.
01:03 alyssa: dEQP-GLES3.functional.fbo.color.blend.* is here, though -- guess poking at that next is up next!
01:03 alyssa: Everything there is passing except for r11g10b11 which I know STK uses.
01:03 alyssa: So I guess getting that test to pass is next up on the agneda.
01:25 imirkin: alyssa: on the off chance you have to convert the 11f/10f values to 16f, it's just a shl
01:25 imirkin: they're just missing a sign bit and some of the mantissa -- exponent is same bit width
01:58 alyssa: imirkin: nir_format_unpack_11f11f10f(...) ;)
01:59 imirkin: it's almost like someone else has run into this
02:00 alyssa: ;D
02:03 alyssa: Anyhow, we have a native op for that but it's not wired in yet and I'd like to get stuff functional before adding opts
02:03 alyssa: (I suspect I need the lowering for earlier models anyhow)
02:11 alyssa: The code looks right...?
02:18 alyssa: Okay what am I missing here
14:50 shakesoda: anyone know which gl/es versions panfrost supports? i can't find it documented anywhere
14:54 shakesoda:can't just check with a device, no hardware on hand yet
15:19 urjaman: currently glxinfo reports GL 2.1, GLES 2.0 (alyssa is working towards GLES 3...) but like it's a very WIP driver (and like the GL 2.1 atleast is not complete, and stuff might be buggy etc)
15:47 pinchartl: could someone pick "[PATCH] drm: of: Fix linking when CONFIG_OF is not set" for drm-misc-next ? it fixes a -next regression
15:47 pinchartl: bbrezillon: ^^ ?
15:54 sravn: pinchartl: the patch has 2x r-b. You could apply it yourself?
16:03 sravn: pinchartl: the offending patch is not in drm-misc-next, it reaches -next by some other tree. In other words your patch does not apply to drm-misc-next. (Out of the door in one minute..)
16:34 pinchartl: sravn: I think it reached -next via drm-next
16:35 pinchartl: so we can either wait for drm-next to be merged in drm-misc-next, or ask danvet or airlied to apply it
16:35 pinchartl: airlied: ^^
19:49 imirkin: chrisf: what's the mechanism for requesting cherry-picks from master into the "real" GL CTS branch?
19:50 imirkin: e.g. it'd be nice to have a851e3adf1 in there
19:50 imirkin: and probably 27d658881f although i haven't investigated
19:54 chrisf: imirkin, propose the cherry-pick yourself into the release branch you want
19:54 chrisf: (on the gerrit)
19:54 imirkin: "the gerrit"?
19:55 chrisf: gerrit.khronos.org is where all the actual work is done
19:55 imirkin: i don't think i have access to that
19:55 imirkin: as an adopter or whatever
19:55 chrisf: should do
19:56 imirkin: how should i request access?
19:56 chrisf: it uses the khronos sso -- so your adopter login should work
19:56 imirkin: it doesn't
19:57 imirkin: like i can get to https://www.khronos.org/opengl/adopters/login/submissions/, for example
19:57 imirkin: but the credentials that get me there don't get me into gerrit/gitlab
20:00 chrisf: huh, i thought mesa people had proper access now
20:01 imirkin: perhaps i didn't get added to some cool people list? dunno
20:06 imirkin: welp, on the bright side, running the mustpass list through glcts yields the same gpu hang as running it through cts-runner
20:06 imirkin: on the donwside ... gpu hang.
21:02 bnieuwenhuizen: chrisf: I think it has to be members still (IIRC adopter also does not do gitlab)
21:04 imirkin: gah! there's a test that makes sure that gl_Layer/gl_PrimitiveID output from a geometry shader is preserved exactly for each vertex in TF, rather than the "overall" value for the triangle
21:04 imirkin: i wonder how nvidia does this ... probably creates a second dummy varying for those?
21:04 imirkin: what an enormous pain
21:05 chrisf: bnieuwenhuizen, alright then
21:08 chrisf: bnieuwenhuizen, SPI is listed now as an option when signing up for a proper member account
21:08 bnieuwenhuizen: hmm, I wonder if that is recent
21:09 imirkin: i followed the instructions early last year, pretty sure i'm just an adopter
21:09 bnieuwenhuizen: yeah my account is just adopter, but that was made like 2 years ago
21:16 imirkin: so this test is just ... silly. "o get defined results, all vertices of each primitive emitted should set the same value for gl_Layer."
21:34 airlied: anholt_: I did some improvements to nir->tgsi once for my vulkan branch but I abandoned them, not sure if still a copy around
21:36 airlied: imirkin: you can also just report things on the public github and make someone else do the work :-p
21:36 chrisf: imirkin, that's a garbage bit of spec language.
21:38 chrisf: there is a query provided which allows you to know exactly what is going to happen, and then that random statement :S
21:44 imirkin: chrisf: well, this is an unfortunate interaction with TF
21:44 imirkin: where for TF, there's a test checking that the value set for each vertex actually flows through to TF
21:44 imirkin: which seems ... dubious
21:44 imirkin: but i'm also not 1000% sure that we handle it for TF at all, so i need to double-check that it's really the hw which sends a single value, vs nouveau screwing things up.
21:44 chrisf: i take it this is inconvenient for your hw
21:45 imirkin: well, i don't really know what the hw does
21:45 imirkin: i don't have a spec
21:45 imirkin: ;)
21:45 imirkin: but whatever the hw does, it's what it does.
21:45 imirkin: before i go filing bugs, i'm going to become convinced that the hw works in the way i think it does
21:48 chrisf: it is *consistent* for this to be outputted properly in TF
21:48 imirkin: if not convenient :)
21:48 chrisf: viewport/layer selection doesnt affect anything upstream of the rasterizer
21:49 imirkin: curiously it's not complaining about viewport ... only layer and primitive id
21:49 imirkin: but it's bogus to be setting them to *different* values in the first place
21:50 imirkin: like ... why would you want that
21:50 chrisf: not particularly useful, but well-defined
21:55 imirkin: hm. well actually looks like it's just getting 0's all the time. so probably not the thing i was thinking of =/
21:57 imirkin: interesting. this is with rasterizer discard, wonder if that screws everything up
22:10 imirkin: of course why that would screw up layer but not viewport... anyone's guess
22:26 imirkin: time to write a piglit to see wtf is going on
23:39 imirkin: hm, ok, no. gl_Layer output seems to work as expected on nvidia hw
23:40 HdkR: :D
23:42 imirkin: as does gl_PrimitiveID
23:42 imirkin: so that CTS test is just doing something funky to confuse everything. SUPER.
23:44 imirkin: and of course we already even had the test for this in piglit, which i find after writing my own... sigh. tests/spec/glsl-1.50/execution/geometry/transform-feedback-builtins.c