[Mesa-dev] OSMesa multiple context problem?
Randall Frank
rjfrank at ensight.com
Wed Sep 21 14:14:39 UTC 2016
Hello,
I have been working around an issue with the OSMesa interface a bit
and was curious if others see this as a bug. An example that triggers
the issue is:
#include <GL/gl.h>
#include <GL/osmesa.h>
#include <stdlib.h>
#include <malloc.h>
int main(int iargs, const char *argv[])
{
void *pBuf0Ptr, *pBuf1Ptr, *pBuf2Ptr;
GLsizei iBuf0Width = 720, iBuf0Height = 480;
GLsizei iBuf1Width = 720, iBuf1Height = 480;
GLsizei iBuf2Width = 120, iBuf2Height = 120;
OSMesaContext ctx0, ctx1;
GLboolean bOk;
pBuf0Ptr = memalign(iBuf0Width*iBuf0Height*4, 4);
pBuf1Ptr = memalign(iBuf1Width*iBuf1Height*4, 4);
pBuf2Ptr = memalign(iBuf2Width*iBuf2Height*4, 4);
ctx0 = OSMesaCreateContext(GL_RGBA, NULL);
ctx1 = OSMesaCreateContext(GL_RGBA, NULL);
bOk = OSMesaMakeCurrent(ctx0, pBuf0Ptr, GL_UNSIGNED_BYTE,
iBuf0Width, iBuf0Height);
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glFlush();
bOk = OSMesaMakeCurrent(ctx1, pBuf1Ptr, GL_UNSIGNED_BYTE,
iBuf1Width, iBuf1Height);
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glFlush();
bOk = OSMesaMakeCurrent(ctx1, pBuf2Ptr, GL_UNSIGNED_BYTE,
iBuf2Width, iBuf2Height);
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glFlush();
bOk = OSMesaMakeCurrent(ctx0, pBuf0Ptr, GL_UNSIGNED_BYTE,
iBuf0Width, iBuf0Height);
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glFlush();
exit(0);
}
When I link this to an gallium enabled Mesa build I get a crash during
the flush to the previous context in osmesa_st_framebuffer_flush_front().
I looked into it a bit and I believe there may be an issue with
osmesa_find_buffer(). Since the two contexts initially use the same size
buffers, this function returns the same osmesa_buffer for each context.
This causes a problem when we change the size of one of the contexts
during an OSMesaMakeCurrent() and it changes the buffer fields that are
effectively (incorrectly?) shared. The flush on the change of context
then crashes...
At least that is my read of the issue. Is this interpretation correct?
If so is there a patch or should we put one together?
--
Thanks
rjf.
-------------------------------------------------------
rjfrank at ensight.com voice:919-363-0883 fax:919-363-0833
Computational Engineering International www.ensight.com
2166 North Salem St, Suite 101, Apex, NC 27523-6456
More information about the mesa-dev
mailing list