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

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

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.

And 'grep -r _mesa_Gen src/mesa/drivers/' shows that we do this all over the place. :(

Welcome to Meta hell. :(

(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.

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.

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.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1498.