03:15anholt_: daniels: it's listed in the CE docks, but as being introduced in gitlab premium. I wonder if we actually have the feature?
07:19daniels: anholt_: right no, we only have core
14:04mmind00: 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:12mmind00: 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:27mmind00: 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:49danvet: mmind00, you need to poke all three (well right now just 2) maintainers to get them to do the backmerge
16:50danvet: so mlankhorst_ and mripard
16:50danvet:no longer in this business, neither is seanpaul
16:51mmind00: danvet: ok thanks for the explanation ... I guess your mention of them should suffice hopefully :-)
17:01ccr: "Do maintainers dream of flawless backmerges?" "I'm not in the business .. I am the business."
20:52austriancoder: trying to fix a linker error I see with pilgit: https://hastebin.com/ukuvagurok.md - DCL OUT, POSITION == DCL IN, TEXCOORD, PERSPECTIVE feels wrong
20:54imirkin: vs out != fs in -- iirc that was never a thing
20:54imirkin: the semantics are used to match
20:55imirkin: without a vs outputting gl_TexCoord, iirc the spec says that texcoord == (0,0,0,1)
20:55imirkin: but one ought to double-check that
20:55austriancoder: I wondered how to handle the not found TGSI_SEMANTIC_TEXCOORD
20:56imirkin: presumably you have PIPE_CAP_I_WANT_TEXCOORD enabled?
20:56imirkin: (not the real name, but i forget)
20:56imirkin: otherwise it should get converted go GENERIC
20:57austriancoder: yes.. PIPE_CAP_TGSI_TEXCOORD
20:57imirkin: 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:57imirkin: unless you have hw which can only do sprite replacement on certain coords, you shouldn't use that semantic, i think
20:57imirkin: [although iirc nir complicates this somehow due to unforced errors? i forget]
20:58imirkin: er, s/on certain coords/on certain varyings/
20:59austriancoder: without that cap I get "Semantic 5 value 0 not found in vertex shader outputs" .. I think need to do some RE
20:59imirkin: well, it's the same thing, no?
20:59imirkin: you get a GENERIC use, and you don't have it in VS output
20:59imirkin: same general idea
21:00imirkin: this can totally happen ... frag shader inputs don't necessary need to have a VS output to match
21:00austriancoder: okay.. found this regarding points: https://github.com/laanwj/etna_viv/blob/master/doc/hardware.md#rendering-points
21:02imirkin: take a look at the if type == frag case
21:02imirkin: basically we feed a (0,0,0,1) in implicitly
21:02austriancoder: got it
21:04imirkin: 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:04imirkin: and you can configure which gl_TexCoord inputs you want to replace
21:04imirkin: this should work even with e.g. glPolygonMode(), so ideally shouldn't involve a shader recalculation
21:05imirkin: although not all hardware can do the y flipping, so it can still require some fiddling
21:06imirkin: curiously, on a3xx+, there's enough support to handle it all.
21:12imirkin: based on those docs, you can only replace one FS input, not multiple FS inputs?
21:13imirkin: 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:14austriancoder: I think that the best is to get some traces from the blob
21:14imirkin: (un)fortunately this is all desktop GL compat stuff
21:14imirkin: with ES, there's only gl_PointCoord, same with GL core
21:29imirkin: not sure if ES 1.1 supports the point sprite replacement stuff
21:34imirkin: aha - OES_point_sprite
21:35imirkin: if your blob supports that, should be fairly easy to trace
23:55austriancoder: yep OES_point_sprite is supported by blob
23:59imirkin: austriancoder: ok, so that looks like it allows you per-texcoord replacement (via glTexEnv)