Comment=
# 5
on bug 97909<=
/a>
from Nicolai H=C3=A4hnle
Okay, so I could reproduce this after all with the web demo.
There is a bug in X-Plane and also questionable behaviour of the driver. The
bug in X-Plane is that it uses GL_AMD_pinned_memory with a size that is not=
a
multiple of a page; as per the spec, the driver is allowed to reject that, =
and
we do (apparently unlike the closed source driver...). X-Plane doesn't check
this error condition, and continues rendering, hence the crash, which would
also happen with a simple sequence of:
glGenBuffers(1, &bo);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, bo);
glDrawElements(...);
Somewhat surprisingly, the OpenGL spec never states that a draw call that g=
oes
outside the element/index buffer should flag a GL_INVALID_OPERATION. There =
is
also no mention of this in the GL_ARB_robust_buffer_access_behavior extensi=
on,
which is surprising.
The patch you provide may or may not go in the right direction - I'm not su=
re.
If we want to check that, we should do it in api_validate.c, but I'm not
convinced that we should. Meanwhile, that check wouldn't properly fix the i=
ssue
in X-Plane. To work around the bug in X-Plane, you need to run with:
MESA_EXTENSION_OVERRIDE=3D-GL_AMD_pinned_memory ./X-Plane-x86_64 --force_run
which will work with an unmodified driver.