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