etnaviv-gpu 134000.gpu: MMU fault status 0x00000002 on i.XM6 Quad Plus

Fri Nov 3 22:48:11 UTC 2017

Hi Russell,

I confirm that the Bug is squashed with that patch. Thanks for the help!

Regards,
Luís

On Fri, Nov 3, 2017 at 4:37 PM, Luís Mendes <luis.p.mendes at gmail.com> wrote:

> Sure, I'll give it a try later. Currently I am working on my day job.
>
> On Fri, Nov 3, 2017 at 4:25 PM, Russell King - ARM Linux <
> linux at armlinux.org.uk> wrote:
>
>> On Fri, Nov 03, 2017 at 12:05:48PM +0000, Luís Mendes wrote:
>> > So this is what I get with picture desc on the candidate corner cases:
>> > Nov  3 11:57:04 picolo xf86_armada[786]: A: clip[x1=0,y1=0],
>> > vSrc[w=1024,h=768], drawable[x=0,y=0], src_offset[x=0,y=0}
>> > Nov  3 11:57:04 picolo xf86_armada[786]: A: Pict:  0x20e45a8: 32
>> > (1024x768+0+0) R fmt XRGB8888
>>
>> I have my own case with mate here:
>>
>> etnaviv_accel_Composite(height=1, width=1,
>>         yDst=0, xDst=0, yMask=0, xMask=0, ySrc=-1, xSrc=-1,
>>         pDst=0x962b08, pMask=0x0, pSrc=0x962ab8, op=PictOpSrc)
>>
>> pSrc = {pDrawable = 0x86cf48, pFormat = 0x59bd78, format = PICT_x8r8g8b8,
>>   refcnt = 1, id = 0, repeat = 0, graphicsExposures = 0, subWindowMode =
>> 1,
>>   polyEdge = 0, polyMode = 0, freeCompClip = 1, componentAlpha = 0,
>>   repeatType = 0, filter = 0, stateChanges = 0, unused = 0, pNext = 0x0,
>>   alphaMap = 0x0, alphaOrigin = {x = 0, y = 0}, clipOrigin = {x = 0, y =
>> 0},
>>   clientClip = 0x0, serialNumber = 4071, pCompositeClip = 0x962b58,
>>   devPrivates = 0x0, transform = 0x0, pSourcePict = 0x0, filter_params =
>> 0x0,
>>   filter_nparams = 0}
>>
>> pSrc->pDrawable = {type = 0, class = 1, depth = 24, bitsPerPixel = 32,
>>   id = 27262979, x = 1334, y = 0, width = 1, height = 25,
>>   pScreen = 0x599708, serialNumber = 4071}
>>    => DRAWABLE_WINDOW
>>
>> pSrc::Pixmap = {drawable = {type = 1, class = 0, depth = 24,
>>     bitsPerPixel = 32, id = 0, x = 0, y = 0, width = 1360, height = 27,
>>     pScreen = 0x599708, serialNumber = 499}, devPrivates = 0x84bd0c,
>>   refcnt = 3, devKind = 5440, devPrivate = {ptr = 0x84bd48, val = 8699208,
>>     uval = 8699208, fptr = 0x84bd48}, screen_x = 0, screen_y = 0,
>>   usage_hint = 536870914, master_pixmap = 0x0}
>>
>> So, what's being asked for is to copy a single pixel from -1,-1 on the
>> source picture to 0,0 on the destination picture.
>>
>> The source picture is a window, with no repeat.  The backing pixmap for
>> the window is 1360x27.  The window is located at 1334,0 on this pixmap.
>>
>> So, -1,-1 is off the top of the window, and off the top of the pixmap.
>>
>> From what I can tell from the Xrender spec
>> (https://www.x.org/releases/current/doc/renderproto/renderproto.txt),
>> this should mean, as repeat mode is "None", that the source should be
>> treated as "transparent".
>>
>> Hmm, let's try to trap the case where the pixels we're asked for are off
>> the pixmap, and use the fallback.  Can you try this patch please?
>>
>> diff --git a/etnaviv/etnaviv_render.c b/etnaviv/etnaviv_render.c
>> index 15cafdf..e846a23 100644
>> --- a/etnaviv/etnaviv_render.c
>> +++ b/etnaviv/etnaviv_render.c
>> @@ -125,24 +125,27 @@ static void etnaviv_debug_blend_op(const char *func,
>>   * determine whether the picture repeat flag is meaningful.  The
>>   * rectangle must have had the transformation applied.
>>   */
>> -static Bool picture_needs_repeat(PicturePtr pPict, int x, int y,
>> +static Bool picture_has_pixels(PicturePtr pPict, int x, int y,
>>         unsigned w, unsigned h)
>>  {
>>         DrawablePtr pDrawable;
>>
>> -       if (!pPict->repeat)
>> -               return FALSE;
>> -
>>         pDrawable = pPict->pDrawable;
>>         if (!pDrawable)
>> +               return FALSE;
>> +
>> +       if (!drawable_contains(pDrawable, x, y, w, h))
>> +               return FALSE;
>> +
>> +       if (!pPict->repeat)
>>                 return TRUE;
>>
>>         if (pPict->filter != PictFilterConvolution &&
>>             (pDrawable->width > 1 || pDrawable->height > 1) &&
>>             drawable_contains(pDrawable, x, y, w, h))
>> -               return FALSE;
>> +               return TRUE;
>>
>> -       return TRUE;
>> +       return FALSE;
>>  }
>>
>>  static const struct etnaviv_blend_op etnaviv_composite_op[] = {
>> @@ -425,8 +428,8 @@ static struct etnaviv_pixmap
>> *etnaviv_acquire_src(ScreenPtr pScreen,
>>         if (!transform_is_integer_translation(pict->transform, &tx, &ty))
>>                 goto fallback;
>>
>> -       if (picture_needs_repeat(pict, src_topleft->x + tx,
>> src_topleft->y + ty,
>> -                                clip->x2, clip->y2))
>> +       if (!picture_has_pixels(pict, src_topleft->x + tx, src_topleft->y
>> + ty,
>> +                               clip->x2, clip->y2))
>>                 goto fallback;
>>
>>         src_topleft->x += drawable->x + src_offset.x + tx;
>> @@ -661,8 +664,8 @@ static int etnaviv_accel_composite_masked(PicturePtr
>> pSrc, PicturePtr pMask,
>>                 mask_offset.y += ty;
>>
>>                 /* We don't handle mask repeats (yet) */
>> -               if (picture_needs_repeat(pMask, mask_offset.x,
>> mask_offset.y,
>> -                                        clip_temp.x2, clip_temp.y2))
>> +               if (!picture_has_pixels(pMask, mask_offset.x,
>> mask_offset.y,
>> +                                       clip_temp.x2, clip_temp.y2))
>>                         goto fallback;
>>
>>                 mask_offset.x += pMask->pDrawable->x;
>>
>>
>> --
>> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
>> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps
>> up
>> According to speedtest.net: 8.21Mbps down 510kbps up
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/etnaviv/attachments/20171103/f27984ff/attachment-0001.html>