Christian GmeinerJul 24, 2025

Funny… I'm investigating some wide_line CTS failures, and for some unknown reason, the blob driver does a second draw with line width 1 after the normal wide line draw. etnaviv does not know about the existence/need of this special draw, which causes the CTS tests to fail.

Starting to question my life choices 🙃

#etnaviv #mesa3d #librem5 #mntreform

Show threadChristian GmeinerFeb 18

So… last night I had plenty of time because everyone else went to bed early - except me.

Test case 'dEQP-GLES3.functional.rasterization.primitives.lines_wide'..
Pass (Pass)

The GPUs hardware line rasterizer doesn't produce spec-conformant results for wide lines - the spec requires them to be rendered as axis-aligned rectangles, offset and replicated in the minor direction.

Need to clean it up but one less todo item 😀

#etnaviv #mesa #mesa3d #librem5 #mntreform

Show threadChristian GmeinerFeb 20

Okay.. I have something for review. I think its quite a nice solution.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40001

#etnaviv #mesa #librem5 #mntreform

etnaviv: Add WIDELINE_TRIANGLE_EMU (!40001) · Merge requests · Mesa / mesa · GitLab

What does this MR do and why? ...

GitLab
Show threadChristian GmeinerFeb 20

@kusma pointed out some issues we might run into if etnaviv starts supporting more advanced features.

Let’s take a simpler approach: disable wide line support on GPUs that would require emulation.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40006

#etnaviv #mesa #librem5 #mntreform

etnaviv: Limit max line width to 1.0 on GPUs needing wide line emulation (!40006) · Merge requests · Mesa / mesa · GitLab

What does this MR do and why? ...

GitLab
Show threadFaith EkstrandFeb 20
@austriancoder @kusma FWIW, I don't didn't trust panfrost to draw lines, either. 🙃
Show threadkusma
@gfxstrand @austriancoder Why not? Mali HW is AFAIK exemplary when it comes to line rasterization robustness...?
Feb 20 at 2:43pmWeb
Show threadFaith EkstrandFeb 20
@kusma @austriancoder I'm very sure the way we just silently bump the sample count for smooth lines will break the moment you have more than one color target. It's doing MSAA but thinks it's not so if we have more than one attachment, they'll end up overlapping in tile memory. It's on the list of things I looked at and went, "I don't know how to fix this with the current FB abstraction".
Show threadFaith EkstrandFeb 20

@kusma @austriancoder Once we switch GL over to pan_fb_layout and friends, it'll be easy enough to have the framebuffer be MSAA but the attachments be single-sampled. But right now, sample counts are taken from image views in all the wrong places.

Also, it currently depends on setting the AVERAGE MSAA write mode and that only works for blendable formats (excluding f16 on V10).

Show threadFaith EkstrandFeb 20
@kusma @austriancoder I should probably file a bug about this but I haven't yet.
Show threadkusmaFeb 20
@gfxstrand @austriancoder I don't have time to look through things ATM, but I wrote that code. I don't think we're doing anything messy with the tile buffers, just the rasterization samples. So I think that's fine.
Show threadFaith EkstrandFeb 20
@kusma @austriancoder That's exactly the problem. We're bumping the framebuffer sample count without adjusting anything else and hoping that's enough. It's not once you get outside the simple cases.
Show threadFaith EkstrandFeb 20

@kusma @austriancoder I wrote down the details in an issue:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/14898

It honestly looks worse than it is. With the new FB abstraction, getting it right should only be a few lines of code (plus hooking up resolve shaders). We just stacked the hacks too high.

panfrost: Smooth lines are broken with MRT and with certain formats (#14898) · Issues · Mesa / mesa · GitLab

Smooth lines are currently implemented in PanVK by smashing the number of samples in the framebuffer to 16: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/panfrost/pan_job.c?ref_type=heads#L477

GitLab