[RS482 Xpress 1100] (Needs radeon-rewrite) Selection mode does not work

Yeah, it's likely related to software fallbacks being somewhat busted in the r300 driver. Interestingly, the Mesa progs/samples/select works here though, same for you?

No, progs/samples/select gives me the same error.

(In reply to comment #2)
> No, progs/samples/select gives me the same error.

Ignore the 'error' output, it just means the driver is 'falling back to software rendering' when the render mode is not GL_RENDER, which is expected.

Do the triangles change colour if you click them with progs/samples/select? If not, which version of Mesa are you using?

It would be interesting to know whether you're using recent Mesa and DRM git.

Other than that, I believe that chip (Radeon Xpress 1100 IGP) has no TCL unit, so perhaps this is a bug that's specific to NO_TCL mode? Just a thought since I can't verify it right now.

The triangles are not changing the colour. On Ubuntu Intrepid I am using Mesa 7.1 rc3 and libdrm2 2.3.1.

Still present in the most recent Ubuntu 8.10 (alpha 6) with version 6.9.0+git20080826 of the radeon driver.

It seems that I am not the only one with that problem, from the Radeon IRC Logs For 2008-10-02:

"[...]
diogo: hey all, still on mesa 7.2 there are problems with gl:select on blender and wings3
[...]
diogo: just the gl select that makes me unhappy"

Maybe this is of interest: When I have compiz enabled, the window of select (from mesademos) looses its borders, as soon as I click on a triangle. Without compiz, this doesn't happen, but still, triangles don't change colour.
Using xserver-xorg-video-radeon 6.9.0+git20081003.f9826a56-0ubuntu2.

Created an attachment (id=19372)
my most recent Xorg.0.log

Created an attachment (id=19373)
my most recent xorg.conf

Maybe this is related to this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=16866
Any way to verify/falsify this?

Works on the same installation (Ubuntu 8.10) with the proprietary catalyst 8.10 driver.

Traditionally, the zbuffer layout is different on low end/IGP variants (i.e. those that are TCL-less). That is the case for r100/r200 and that would be consistent with the fact that this bug is only seen on those chips, so I'd wager this geenralizes to r300 as well. Did anyone dig into that possibility ? Basically you'd just need to fix the span code in mesa.

(In reply to comment #13)
> Traditionally, the zbuffer layout is different on low end/IGP variants (i.e.
> those that are TCL-less). That is the case for r100/r200 and that would be
> consistent with the fact that this bug is only seen on those chips, so I'd
> wager this geenralizes to r300 as well. Did anyone dig into that possibility ?
> Basically you'd just need to fix the span code in mesa.
But tile translation should be handled by the chip itself (except there was a bug with the tcl-less r100), by use of the tiling regions. This should work the same no matter what the layout actually is. Unless the surface bits would have different meaning for some r300 based chips or there are some other options with tile configuration...

Created an attachment (id=19691)
Patch

Try this patch.

(In reply to comment #15)
> Created an attachment (id=19691) [details]
> Patch
>
> Try this patch.

This is already fixed in master. Though I realize now there's actually a bug in the fix there, "screen->chip_family & RADEON_CLASS_R100" will always be false - that should have been "(screen->chip_flags & RADEON_CLASS_MASK) == RADEON_CLASS_R100" (I'll fix this). Anyway, it has the same effect on r300 chips as your patch.

(In reply to comment #16)
> (In reply to comment #15)
> > Created an attachment (id=19691) [details] [details]
> > Patch
> >
> > Try this patch.
>
> This is already fixed in master. Though I realize now there's actually a bug in
> the fix there, "screen->chip_family & RADEON_CLASS_R100" will always be false -
> that should have been "(screen->chip_flags & RADEON_CLASS_MASK) ==
> RADEON_CLASS_R100" (I'll fix this). Anyway, it has the same effect on r300
> chips as your patch.
>

Hmm right I used a stale mesa tree.

Anyway, surfaces are not magic as you seem to imply. If you put one in front of a piece of memory, it applies the tiling function, whether the buffer is tiled or linear (in which case you scramble the contents). Here is what I think is the problem :
- the (low end) card doesn't tile the zbuffer
- we still setup the tile registers over the zbuffer
- reads are scrambled by the use of a surface. If the surface wasn't there, zbuffer reads would work

(In reply to comment #17)
> Anyway, surfaces are not magic as you seem to imply. If you put one in front of
> a piece of memory, it applies the tiling function, whether the buffer is tiled
> or linear (in which case you scramble the contents). Here is what I think is
> the problem :
> - the (low end) card doesn't tile the zbuffer
> - we still setup the tile registers over the zbuffer
> - reads are scrambled by the use of a surface. If the surface wasn't there,
> zbuffer reads would work
>

Oh, I didn't want to imply surfaces are magic. But I think only non-tcl r100-class chips don't use tiling for the z buffer.
But if that's indeed some bogus surface setup, you can verify that with mesa's progs/zreaddraw demo, which wouldn't work in this case.

Created an attachment (id=19873)
r300_fallback

R300 fallback to _tnl_render_stage when we have problem with hardware TCL, but it not fallback to _swrastr when we have problem with hardware rasterization.

Tested on rs740.

Changes with this patch:
1. Add fallback to swrastr like in other radeon/r200
2. Small clean up useless things relation to fallback.
3. Add prefix TCL to things relation with TCL fallback.
4. Exclude useless warning (like in first post) when we don't have hardware TCL.

Not sure what we shall do when we have hardware TCL, but have problem with rasterization. Possibly we shall review current TCL fallback in r300_render.c and do it like in radeon/r200.

Also not sure where hardware supported by r300 have problem and should fallback to swrastr.

What about this?

I get the message with Mesa progs/samples/select with and without the patch on r300 (RV350 AS [Radeon 9550]) but colour changes.

>I get the message with Mesa progs/samples/select with and without the patch on
>r300 (RV350 AS [Radeon 9550]) but colour changes.

Wath message? This patch needed only when we have problem with hardware rasterization (RS690/RS740 and possible other IGP).

Still there using version 6.11.0-1ubuntu5 on a Ubuntu 9.04 installation, RS482 [Radeon Xpress 200M].
Performance of glxgears has also dropped by factor 3 now, but that is probably another issue, :(

I've found out that software rasterizer fallbacks are broken when HW TCL is disabled.
Basically it's because in r300InitSwtcl we plug our custom functions for rendering, and when we hit rasterizer fallback we don't call _swsetup_Wakeup. Also looks like we don't flush when switching between HW<->SW rendering which could lead to rendering errors or maybe even GPU lockups.

I'm reimplementing fallbacks handling on r300 so it should be fixed soon.

Fixed since 2240c0d33365189f975b84b06792e2a5ecb8b13a in radeon-rewrite branch.
Closing