01:21 <marex> austriancoder: could it be that the real problem with the TXP is that w=0 , and therefore the RCP triggers division by zero ?

12:33 <marex> lynxeye: hey, you around are available for discussing etnaviv fixed pipeline bugs ?

12:38 <mntmn> marex: btw you were messing with imx8mn, or do i remember that wrong? how is that going?

12:39 <marex> mntmn: I have one on my desk, why ?

12:40 <mntmn> marex: i want to possibly use it for a small device, and a friend might use it for a retro related thing

12:41 <mntmn> marex: how is the etnaviv support?

12:41 <marex> I didnt try etnaviv on it yet, but its GC7000UL, so it should be fine

12:41 <mntmn> ok

12:41 <mntmn> there was some trouble with power mgmt?

12:42 <marex> just the usual

12:43 <marex> you need the power domain driver and blk_ctl

12:58 <lynxeye> marex: what kind of bugs?

13:00 <lynxeye> mntmn: 8mn has the same gpu as 8mp afaik, which is a bit a weird crossover between the new GC7000 on 8mq and some older GPUs. It doesn't have the BLT engine and needs some work in that area if I'm right. I'm going to take a look at fixing the 8mp support in the next days.

13:03 <marex> lynxeye: BLT -- bacon lattuce tomato ?

13:03 <marex> (sorry, I had to)

13:03 <mntmn> lynxeye: ok, cool

13:04 <lynxeye> marex: hehe

13:04 <marex> lynxeye: eglretrace https://github.com/ptitSeb/gl4es/blob/master/traces/pointsprite.tgz

13:04 <marex> lynxeye: this ends up setting W in gl_TexCoord, which is wrong

13:04 <marex> lynxeye: see https://gitlab.freedesktop.org/marex/mesa/-/commit/daafe97bbfe9fc5e33d0d986b668c9006846b1ac patch which works around the problem and fixes that eglretrace (and point sprites in neverball)

13:05 <marex> lynxeye: I think we either have to handle W=0 in the RCP input in TGSI TXP instruction (and similar to NIR) because that triggers division by zero (rcp 1.0/0.0) or avoid W=0 in the first place

13:06 <lynxeye> marex: Urgh, points. Never looked too much at them and AFAIK the way things are specified in the varying changed multiple time over GPU generations :/

13:08 <marex> lynxeye: with that patch, the example works on GC400/2000/7000L, so I think we're pretty close to getting that right

13:09 <marex> its just this last thing with W=0

13:09 <lynxeye> marex: That patch seems pretty bogus, at least the comment changes. texcoords have very well defined outputs from the VS.

13:10 <marex> lynxeye: it is marked FIXME for a reason

13:15 <marex> at least now we know the problem is with the W component or with generating TXP instruction for sampling the texcoord in the first place

13:23 <lynxeye> marex: I do think 4e102a6de72667c1177e7c484d72bf1d94d028ca is bogus, as I did the varying configuration before this commit based on a GC3000 trace and it at least yielded correct results for flat shaded varyings, which is broken by this commit.

13:23 <lynxeye> marex: What are the values of W you are seeing with this example?

13:24 <marex> lynxeye: is there some good way to extract them ? If i write them to the texture output, its 0

13:26 <austriancoder> lynxeye: 4e102a6de72667c1177e7c484d72bf1d94d028ca is okay afaict from my traces

13:27 <marex> austriancoder: oh hey, look how much progress I've made last night ;-)

13:27 <lynxeye> austriancoder: it's definitely breaking flat shading. There's around 600 piglits to prove it ;)

13:28 <austriancoder> lynxeye: I can only tell you what I see..

13:28 <marex> lynxeye: which ones ?

13:28 <austriancoder> marex: I have old traces

13:28 <marex> austriancoder: old traces of what ?

13:29 <lynxeye> marex: clipflat, which has a lot of subtests...

13:31 <austriancoder> marex: of a simple test

13:32 <marex> austriancoder: for the point sprites ?

13:34 <lynxeye> marex: why is the frontend even using a TXP for the point sprite texture sampling?

13:34 <austriancoder> marex: if I remember correctly.. yes .. I dig for it .. but not now as I am working for my day job

13:34 <marex> lynxeye: "at least now we know the problem is with the W component or with generating TXP instruction for sampling the texcoord in the first place"

13:35 <marex> lynxeye: so I was hoping you can answer that question ;-)

13:35 <lynxeye> austriancoder: I'm just saying that the blob isn't always correct, especially with things that aren't covered by GLES.

13:36 <austriancoder> lynxeye: I am aware of that fact.. thats why I often write simple demos to prove stuff visually

13:36 <lynxeye> marex: Ah, apparently my mind skipped over the second half of the sentence ;)

13:40 <lynxeye> marex: From a quick read on point sprite behavior I don't see why those should use projective texture mapping, so I would expect to see a TEX instruction instead.

13:43 <marex> lynxeye: I can imagine someone might supply a projection component (W) to texcoord (?)

13:43 <marex> that's what the tex->projector is for in the load_texture()

13:45 <lynxeye> marex: For points the texture coordinates are autogenerated with a range of 0,0 to 1,1 across the point. That's the point of GL_POINTS afaics, so I don't see a way to supply a sensible W there.

13:46 <marex> lynxeye: seems like the load_texture is not only for points

13:46 <marex> lynxeye: so maybe the bug is in the fixed pipeline implementation itself

14:07 <lynxeye> marex: Maybe. The code is not that easy to follow, but it seems there is also a common GLSL IR level projection lowering that we aren't using. Maybe that one also cleans up some of the madness through const propagation...

14:11 <marex> lynxeye: what should I git grep for ?

14:13 <lynxeye> marex: The one I found is do_lower_texture_projection

14:14 <lynxeye> But I guess there are people in #dri-devel that know much more about this crazy point sprite stuff than I will ever want to know. So maybe give it a shot to ask why we end up with TXP over there?

14:14 <marex> lynxeye: good idea, thanks

14:19 <austriancoder> that lowering is not used by ir_to_mesa so it might make also sense to use a tgis based software renderer and see if the generated tgsi shader also uses txp

14:19 <marex> austriancoder: i.e. LIBGL_ALWAYS_SOFTWARE=1 MESA_GLSL=dump ?

14:20 <marex> and also MESA_DEBUG=all or somesuch

14:28 <austriancoder> marex: and some software renderer specific debug flag like for llvmpipe LP_DEBUG=tgsi

14:31 <marex> austriancoder: well at least LIBGL_ALWAYS_SOFTWARE renders the point sprites correctly

14:31 <marex> austriancoder: I need to check what code it generates, that's for later