[Bug 15334] New: Radeon EXA + Sampling off the edge of REPEAT_NONE sources

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=15334

           Summary: Radeon EXA + Sampling off the edge of REPEAT_NONE
                    sources
           Product: xorg
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/Radeon
        AssignedTo: xorg-driver-ati at lists.x.org
        ReportedBy: otaylor at redhat.com
         QAContact: xorg-team at lists.x.org


Created an attachment (id=15640)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=15640)
Patch fixing repeating transformed sources

REPEAT_NONE (The default pixman repeat mode) is being handled in
the Radeon EXA code render acceleration code incorrectly ... the
current behavior is pretty much what REPEAT_PAD is supposed to
do, while REPEAT_NONE should give alpha=0 pixels when sampling
off the edge.

This is easy to do using the border color feature of the hardware
when the source pixmap has alpha, but since the border color
register is in the same format as the source pixmap, I don't
how to solve the issue in the no-alpha source case, so the
attached patch just falls back.

Notes:

 - The same issue is almost certainly present for R100/R200,
   but lacking both experience and hardware in that area I
   haven't tried to address it.

 - The handling of untransformed sources may not be right
   if the upper layers don't clip the rendered area to the
   source bounds. (cairo does this on the client side, so
   my test program didn't reveal this one way or the other
   and I don't want to dig through the code right now.)

   The correct fix if that isn't happening would be to add
   that clipping, since it's a significant optimization,
   and a common case where you don't want to fall back to
   software.

 - It would be theoretically possible to detect that the
   sampled area is entirely within the source and avoid
   the fallback for non-alpha sources but it would be hard
   and I think it's a rare case not worth worrying about.

 - The names for the clamp modes in radeon_reg.h are 
   not at obvious to me:

#       define R300_TX_CLAMP_WRAP                       0
#       define R300_TX_CLAMP_MIRROR                     1
#       define R300_TX_CLAMP_CLAMP_LAST                 2
#       define R300_TX_CLAMP_MIRROR_CLAMP_LAST          3
#       define R300_TX_CLAMP_CLAMP_BORDER               4
#       define R300_TX_CLAMP_MIRROR_CLAMP_BORDER        5
#       define R300_TX_CLAMP_CLAMP_GL                   6
#       define R300_TX_CLAMP_MIRROR_CLAMP_GL            7

   CLAMP_GL seems to correspond to GL_CLAMP_TO_BORDER
   which I believe was added later in GL and not to GL_CLAMP.
   The corresponding #defines in Mesa make more sense to me:

#       define R300_TX_REPEAT                    0
#       define R300_TX_MIRRORED                  1
#       define R300_TX_CLAMP_TO_EDGE             2
#       define R300_TX_MIRROR_ONCE_TO_EDGE       3
#       define R300_TX_CLAMP                     4
#       define R300_TX_MIRROR_ONCE               5
#       define R300_TX_CLAMP_TO_BORDER           6
#       define R300_TX_MIRROR_ONCE_TO_BORDER     7

   But I don't understand this well enough to say if the 
   correspondence to GL is really exact enough to merit those
   names. The r500 docs document the values as:

   00 - Wrap (repeat)
   01 - Mirror
   02 - Clamp to last texel (0.0 to 1.0)
   03 - MirrorOnce to last texel (-1.0 to 1.0) 
   04 - Clamp half way to border color (0.0 to 1.0)
   05 - MirrorOnce half way to border color (-1.0 to 1.0)
   06 - Clamp to border color (0.0 to 1.0)
   07 - MirrorOnce to border color (-1.0 to 1.0)

  Anyways, a digression...


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.