00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Acer Incorporated [ALI] Device 071a
        Flags: bus master, fast devsel, latency 0, IRQ 44
        Memory at c1000000 (64-bit, non-prefetchable) [size=4M]
        Memory at b0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 3000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [a4] PCI Advanced Features
        Kernel driver in use: i915

Created attachment 97217 [details]
glxinfo

I see the same failure with LIBGL_ALWAYS_SOFTWARE=1.

Created attachment 143726 [details]
trace with issue on Intel

I tested this issue and it still there.

I using qapitrace to check results of a frame 0.
Intel shows just a blue screen
Radeon shows a small blue rect in a green rect which is in a red rect.
I will attach that screens here shortly.

Created attachment 143727 [details]
Small explanation of a wine test

I am still working on a piglit test for this issue:
https://gitlab.freedesktop.org/mesa/piglit/merge_requests/18

and on a mesa fix for it:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/466

Seems 'Step 2' mentioned on the attached picture doesn't
work on Intel. It just clean (with depth value 0.0) the whole
depth buffer size ignoring the scissors and as result depth test 
doesn't accept green and red rectangles at all because their z > 0.0.

I tested an Iris driver with MR "iris: Add fast clear support." using my piglit test and this issue isn't reproduced there. Gallium state tracker function 'is_scissor_enabled' checks a depth render buffer size (and this behavior looks more correct for me):
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/state_tracker/st_cb_clear.c#L469-479

instead of a frame buffer size, like in i965:
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/brw_clear.c#L117-127

I made a mistake, this isn't a mesa issue.
According to ARB_framebuffer_object spec:

  "- If the attachment sizes are not all identical, rendering will be
   limited to the largest area that can fit in all of the
   attachments (i.e. an intersection of rectangles having a lower
   left of (0,0) and an upper right of (width,height) for each
   attachment)

   - If the attachment sizes are not all identical, the values of
   pixels outside the common intersection area after rendering are
   undefined."

So this is rather a wine issue.
************************
*   depth              *
*                      *
***********            *
* color   *            *
*         *            *
*         *            *
************************
Because it does not expect that depth buffer will be
modified outside the scissors area which is equal
to intersection area.

But Mesa feels free to do everything with pixels(depth)
outside the intersection area even to clean them.

Gallium behaves here in another way it just leaves
a depth buffer outside the intersection untouched.

(In reply to andrii simiklit from comment #7)
> I made a mistake, this isn't a mesa issue.
> According to ARB_framebuffer_object spec:
> 
>   "- If the attachment sizes are not all identical, rendering will be
>    limited to the largest area that can fit in all of the
>    attachments (i.e. an intersection of rectangles having a lower
>    left of (0,0) and an upper right of (width,height) for each
>    attachment)
> 
>    - If the attachment sizes are not all identical, the values of
>    pixels outside the common intersection area after rendering are
>    undefined."
> 
> So this is rather a wine issue.
> ************************
> *   depth              *
> *                      *
> ***********            *
> * color   *            *
> *         *            *
> *         *            *
> ************************
> Because it does not expect that depth buffer will be
> modified outside the scissors area which is equal
> to intersection area.
> 
> But Mesa feels free to do everything with pixels(depth)
> outside the intersection area even to clean them.
> 
> Gallium behaves here in another way it just leaves
> a depth buffer outside the intersection untouched.

Based on opengl calls the original wine test makes the following steps:
1. creates a fbo (FA)
2. creates a depth buffer (DA) with size 640x480
3. creates a color buffer (CA) with the same size 640x480
4. attaches (CA) and (DA) to (FA)
5. calls a glClear  with depth 1.0 and blue color using (FA)
6. creates another fbo (FB)
7. creates a color buffer (CB) with size 320x240
8. attaches (CB) and (DA) to (FB)
9. setups a scissors area for 320x240
10. calls a glClear with depth 0.0 and white color using (FB)

Test expects that the depth outside 320x240 area
is not modified and there is still 1.0 but according
to spec which was mentioned above this is undefined behavior.

I suggest to close this issue as a not mesa issue.

I redirected this issue to wine bugzilla:
https://bugs.winehq.org/show_bug.cgi?id=46917