03:15 anholt_: daniels: it's listed in the CE docks, but as being introduced in gitlab premium. I wonder if we actually have the feature?
03:16 anholt_: docs
07:19 daniels: anholt_: right no, we only have core
14:04 mmind00: is there a process on getting stuff from v5.5-rc1 into drm-misc-next? It still seems to be at 5.4-rc4 right now ...
14:12 mmind00: as right now I'm missing the somewhat new PHY_MODE_LVDS constant from https://elixir.bootlin.com/linux/v5.5-rc1/source/include/linux/phy/phy.h#L42 for an lvds driver
16:27 mmind00: so from looking through drm-misc history (and the v5.4-rc4 merge), it looks like poking danvet or seanpaul for merging v5.5-rc1 to get commit 711b2bfba748 ("phy: add PHY_MODE_LVDS") into drm-misc-next might be way to go?
16:49 danvet: mmind00, you need to poke all three (well right now just 2) maintainers to get them to do the backmerge
16:50 danvet: so mlankhorst_ and mripard
16:50 danvet:no longer in this business, neither is seanpaul
16:51 mmind00: danvet: ok thanks for the explanation ... I guess your mention of them should suffice hopefully :-)
17:01 ccr: "Do maintainers dream of flawless backmerges?" "I'm not in the business .. I am the business."
20:52 austriancoder: trying to fix a linker error I see with pilgit: https://hastebin.com/ukuvagurok.md - DCL OUT[0], POSITION == DCL IN[0], TEXCOORD[0], PERSPECTIVE feels wrong
20:53 imirkin: why?
20:54 imirkin: vs out[0] != fs in[0] -- iirc that was never a thing
20:54 austriancoder: sure
20:54 imirkin: the semantics are used to match
20:55 imirkin: without a vs outputting gl_TexCoord, iirc the spec says that texcoord == (0,0,0,1)
20:55 imirkin: but one ought to double-check that
20:55 austriancoder: aha
20:55 austriancoder: I wondered how to handle the not found TGSI_SEMANTIC_TEXCOORD
20:55 imirkin: well
20:56 imirkin: presumably you have PIPE_CAP_I_WANT_TEXCOORD enabled?
20:56 imirkin: (not the real name, but i forget)
20:56 imirkin: otherwise it should get converted go GENERIC[]
20:57 austriancoder: yes.. PIPE_CAP_TGSI_TEXCOORD
20:57 imirkin: the texcoord stuff was originally created for nouveau ... on nvc0, there's a special set of shader inputs that map to the texcoord + sprite replacement logic
20:57 imirkin: unless you have hw which can only do sprite replacement on certain coords, you shouldn't use that semantic, i think
20:57 imirkin: [although iirc nir complicates this somehow due to unforced errors? i forget]
20:58 imirkin: er, s/on certain coords/on certain varyings/
20:59 austriancoder: without that cap I get "Semantic 5 value 0 not found in vertex shader outputs" .. I think need to do some RE
20:59 imirkin: well, it's the same thing, no?
20:59 imirkin: you get a GENERIC use, and you don't have it in VS output
20:59 imirkin: same general idea
21:00 imirkin: this can totally happen ... frag shader inputs don't necessary need to have a VS output to match
21:00 austriancoder: okay.. found this regarding points: https://github.com/laanwj/etna_viv/blob/master/doc/hardware.md#rendering-points
21:01 imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp#n2084
21:02 imirkin: take a look at the if type == frag case
21:02 imirkin: basically we feed a (0,0,0,1) in implicitly
21:02 austriancoder: got it
21:04 imirkin: so ... sprite coord is basically if you have a frag shader which consumes gl_TexCoord[] but is being drawn to rasterize points, those gl_TexCoord accesses implicitly map to, effectively, gl_PointCoord
21:04 imirkin: and you can configure which gl_TexCoord[] inputs you want to replace
21:04 imirkin: this should work even with e.g. glPolygonMode(), so ideally shouldn't involve a shader recalculation
21:05 imirkin: although not all hardware can do the y flipping, so it can still require some fiddling
21:06 imirkin: curiously, on a3xx+, there's enough support to handle it all.
21:12 imirkin: based on those docs, you can only replace one FS input, not multiple FS inputs?
21:13 imirkin: also, annoyingly, there's software that relies on that gl_TexCoord to read out as (x,y,0,1) ... iirc that simple games where the stars are rendered using points
21:14 austriancoder: I think that the best is to get some traces from the blob
21:14 imirkin: (un)fortunately this is all desktop GL compat stuff
21:14 imirkin: with ES, there's only gl_PointCoord, same with GL core
21:29 imirkin: not sure if ES 1.1 supports the point sprite replacement stuff
21:34 imirkin: aha - OES_point_sprite
21:35 imirkin: if your blob supports that, should be fairly easy to trace
23:55 austriancoder: yep OES_point_sprite is supported by blob
23:59 imirkin: austriancoder: ok, so that looks like it allows you per-texcoord replacement (via glTexEnv)