Bug 92363 - [BSW/BDW] ogles1conform Gets test fails
Summary: [BSW/BDW] ogles1conform Gets test fails
Status: ASSIGNED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-09 16:24 UTC by cprigent
Modified: 2015-11-11 12:35 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cprigent 2015-10-09 16:24:33 UTC
Platform: Braswell M 
CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping: 4)
SoC : BSW D0
QDF : K6XC
CRB : BRASWELL RVP Fab2
Mandatory Reworks : All 
Feature Reworks: F28, F32, F33, F35, F37
Optional reworks : O-01a; O-02, O-03
Software 
Linux distribution: Ubuntu 14.04 LTS 64 bits 
BIOS : BRAS.X64.B084.R00.1508310642
TXE FW : 2.0.0.2073
Ksc : 1.08

kernel drm-intel-nightly 4.3.0-rc3 eb69e51 from anongit.freedesktop.org/drm-intel

mesa: (HEAD, tag: mesa-11.0.2) 51e0b06d9916e126060c0d218de1aaa4e5a4ce26 from
git://git.freedesktop.org/git/mesa/mesa

cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d from
git://git.freedesktop.org/git/cairo
drm: (HEAD, tag: libdrm-2.4.64, tag: 2.4.64)
ab2fadabde3829b1ec56bd4756165dd9bd281488 from
git://git.freedesktop.org/git/mesa/drm
intel-driver: (HEAD, origin/master, origin/HEAD, master)
2a72f99d24714f2a58f400ef63b913d4cf9080b3 from
git://git.freedesktop.org/git/vaapi/intel-driver
libva: (HEAD, tag: libva-1.6.1, origin/v1.6-branch)
613eb962b45fbbd1526d751e88e0d8897af6c0e0 from
git://git.freedesktop.org/git/vaapi/libva
xf86-video-intel: (HEAD, origin/master, origin/HEAD, master)
f0fd4d500de03c30c7ce19915f85acadd1ca4e5d from
git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
xserver: (HEAD, tag: xorg-server-1.17.2)
2123f7682d522619f101b05fb75efa75dabbe371 from
git://git.freedesktop.org/git/xorg/xserver
intel-gpu-tools: (HEAD, origin/master, origin/HEAD, master)
1b492e311ce13fe4bc42f1edd5479441662d4855 from
git://git.freedesktop.org/git/xorg/app/intel-gpu-tools

Steps:
------
Execute command:
./conform

Actual result:
---------------
"Gets test" is fail

Expected result:
-----------------
"Gets test" is Pass
Comment 1 cprigent 2015-10-20 08:02:58 UTC
Reproduced with Mesa 11.0.3

Platform: Braswell M
CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping: 4)
SoC : BSW D0
QDF : K6XC
CRB : BRASWELL RVP Fab2
Mandatory Reworks : All 
Feature Reworks: F28, F32, F33, F35, F37
Optional reworks : O-01a; O-02, O-03

BIOS : BRAS.X64.B084.R00.1508310642
TXE FW : 2.0.0.2073
Ksc : 1.08
Linux distribution: Ubuntu 14.04 LTS 64 bits
kernel 4.3.0-rc5-drm-intel-nightly+ 819f710081d7ea116b9b44a9264061d2c030f009 from git://anongit.freedesktop.org/drm-intel
Mesa - 11.0.3 from http://cgit.freedesktop.org/mesa/mesa/
xf86-video-intel - 2.99.917 from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/
Libdrm - 2.4.65 from http://cgit.freedesktop.org/mesa/drm/
Libva - 1.6.1 from http://cgit.freedesktop.org/libva/
vaapi intel-driver - 1.6.1 from http://cgit.freedesktop.org/vaapi/intel-driver
Cairo - 1.14.2 from http://cgit.freedesktop.org/cairo
Xorg Xserver - 1.17.2 from http://cgit.freedesktop.org/xorg/xserver

Kernel commit 819f710081d7ea116b9b44a9264061d2c030f009
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Oct 14 19:05:17 2015 +0200
drm-intel-nightly: 2015y-10m-14d-17h-04m-36s UTC integration manifest
Comment 2 Elio 2015-10-21 16:53:35 UTC
Problem is present on BDW with following configuration:

Broadwell-U
Hardware
Platform: NUC5i7RYB
Processor: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
GPU: Broadwell-U Integrated Graphics
Software
Linux distribution: Ubuntu 14.04 LTS 64 bits

kernel 4.3.0-rc5-drm-intel-nightly+  from git://anongit.freedesktop.org/drm-intel
Mesa - 11.0-branchpoint-1379-g6f39556 http://cgit.freedesktop.org/mesa/mesa/
xf86-video-intel - 2.99.917 from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/
Libdrm - 2.4.65 from http://cgit.freedesktop.org/mesa/drm/
Libva - 1.6.1 from http://cgit.freedesktop.org/libva/
vaapi intel-driver - 1.6.1 from http://cgit.freedesktop.org/vaapi/intel-driver
Cairo - 1.14.2 from http://cgit.freedesktop.org/cairo
Xorg Xserver - 1.17.2 from http://cgit.freedesktop.org/xorg/xserver
Comment 3 Ian Romanick 2015-11-02 19:11:20 UTC
This is actually a pretty significant bug that appears to have existed since commit 2f28a0dc... which landed in master in August 2014.  Here's the problem...

In OpenGL ES (all versions!) and OpenGL compatibility profile, applications don't have to call Gen functions.  This comes from the old days of textures and display lists where applications wanted to do clever things like make a display list that drew the letter "A" named (GLint)'A'.  The GL spec is very clear about how you can mix-and-match generated names and non-generated names: you can use any name you want for a particular object type until you call the Gen function for that object type.

Enter brw_meta_fast_clear which calls brw_fast_clear_init which calls _mesa_GenVertexArrays and _mesa_GenBuffers.  A perfectly valid application could do something like:

    glClear(GL_COLOR_BUFFER_BIT);

    // bind my cool buffer
    glBindBuffer(GL_ARRAY_BUFFER, 1);
    glBufferData(GL_ARRAY_BUFFER, ...);

    glClear(GL_COLOR_BUFFER_BIT);

    // draw using the data in my cool buffer
    glDrawArrays(...);

Too bad the second call to glClear smashed the data the application put in its buffer.
Comment 4 Ian Romanick 2015-11-02 19:12:20 UTC
And 'grep -r _mesa_Gen src/mesa/drivers/' shows that we do this all over the place. :(
Comment 5 Kenneth Graunke 2015-11-04 09:02:41 UTC
Welcome to Meta hell. :(
Comment 6 Ian Romanick 2015-11-04 18:33:40 UTC
(In reply to Kenneth Graunke from comment #5)
> Welcome to Meta hell. :(

Yeah... I already have about a dozen patches just for VBOs in meta.  The good news is that I think it's a general improvement to meta.
Comment 7 Ian Romanick 2015-11-06 18:59:20 UTC
As this gets fixed, we'll need a set of piglit tests targeted at this problem.  Each meta operation needs to be verified against each type of object that can have user-defined names.  Each individual test should flow like:

    glSomeOperation();

    for (i = 1; i < 15; i++)
        create_and_fill_data_in_object(i);

    glSomeOperation();

    for (i = 1; i < 15; i++)
        verify_data_in_object(i);

Using a couple tables of function pointers should make a general test runner failry straight forward.  It should also make it easy to extend to future meta operations.

struct gl_operation operations[] = {
    { "glClear", do_glClear },
    { "glBitmap", do_glBitmap },
    // ...
};

struct gl_oject_types object_types[] = {
    { "buffer", create_buffer_object, verify_buffer_object },
    { "texture", create_texture, verify_texture },
    // ...
};

My preference would be to land the tests piece by piece.  Have one patch that adds the framework, a single object type, and a single meta operation.  This would be followed by patches for each object type, and those would be followed by patches for each additional meta operation.  That should make the whole thing easier to review.

The framework should allow individual tests to be run:

./meta_versus_Gen glClear texture

The following object types, in priority order) need to be tested:

 - buffer object
 - texture
 - sampler
 - framebuffer
 - renderbuffer
 - vertex program (from GL_ARB_vertex_program)
 - fragment program (from GL_ARB_fragment_program)
 - vertex array object (from GL_APPLE_vertex_array_object)
 - fragment shaders (from GL_ATI_fragment_shader)
 - queries (this will be tricky... leave until last)

Many object types (ARB vertex array objects, transform feedback objects, program pipeline objects, GLSL shader / program objects, Intel performance query objects, etc.) do not need to be tested because user-defined names cannot be used with those object types.

Some object types (NVIDIA or APPLE fences, EXT vertex shaders, NVIDIA transform feedback objects) do not need to be tested because Mesa does not support them.

GL_AMD_performance_monitor does not specify whether or not Gen'ed names must be used.

All the possible meta operations must be tested:

 - glClear
 - glBitmap
 - glBlitFramebuffer
 - glCopyImageSubData
 - glCopyPixels
 - glDrawPixels
 - glGenerateMipmap
 - glCopyTexSubImage
 - glClearTexSubImage
 - glTexSubImage (from a PBO)
 - glGetTexSubImage (to a PBO)
 - glDrawTex (OpenGL ES 1.1)

There may be others.  This was the list I found by looking at src/mesa/drivers/common/meta.h.  There are some additional meta ops in the i965 driver.
Comment 8 Ian Romanick 2015-11-11 03:02:51 UTC
While working on this fix, it occurs to me that meta has another potentially serious problem.

Many GL objects can be shared between contexts.  If one thread deletes an object while it is still bound in another context, that object continues to exist until it's unbound.  Meta does an awful lot of unbinding of objects... and expects those objects to not vanish. :(

To go along with the previous tests, we need a test that creates two contexts in the same share group.  Each context is made current in a different thread.  For each object type, for each meta operation, thread A:

    - Creates and binds the object.

    - Sends a message (through some means) to thread B.

    - Wait for ACK from thread B.

    - Perform the meta operation

    - Verify:

        - No GL error was generated.

        - The object is still bound.

        - The object still has the correct data.

Thread B just sits in a loop:

    - Wait for a message from thread A.

    - Perform the action of the message (i.e., delete the object).

    - ACK thread A.

I'm envisioning two pthread_cond_t objects (one to signal a message is ready, and one to signal the operation is complete) and a single structure like:

struct delete_command {
    enum {
        texture, buffer, framebuffer, renderbuffer, sampler, etc;
    } object_type;
    GLuint object_name;
} command;

used to communicate between the two threads.

The other set of tests is definitely the higher priority.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.