[Mesa-dev] [Bug 95215] ARB_shading_language_include is not implemented

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Apr 30 21:06:47 UTC 2016


--- Comment #2 from Jamey Sharp <jamey at minilop.net> ---
(In reply to Ilia Mirkin from comment #1)
> Sounds like the game is buggy and needs fixing - I presume it runs fine on
> Catalyst drivers, which also don't support the ext.

Hmm. Is apitrace mis-leading us here?

`nm -D` tells me that the only uses of NamedStringARB are in libOGLBinding.so,
shipped with the game. Specifically it uses the __glewNamedStringARB function

`readelf --relocs libOGLBinding.so | grep __glewNamedStringARB` tells me the
address of that function pointer is written to offset 29c68, which I find used
twice in `objdump -d libOGLBinding.so`.

In both cases, the following instructions check that the function pointer is
not null. Inside `api::OpenGLRenderer::CreateShader(ls::ObjectHandle)`, if the
function pointer is null, it calls
`api::OpenGLRenderer::EmbedIncludes(ls::STDString&)`, which sounds sensible.
Inside `api::OpenGLRenderer::CreateShader(ls::ObjectHandle)` the fallback goes
to a function that isn't in the symbol table, but it does a bunch of string
manipulation so I'm going to guess it's probably similar.

So: Does apitrace make __glewNamedStringARB non-null even when the function
isn't available in the underlying driver? If so, then we're following a
different code path in the game when we trace it. If that's the case, then this
bug has nothing to do with any remaining rendering issues, but it would be nice
to know how to make apitrace not do that so we can find real bugs.

You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160430/11091b90/attachment.html>

More information about the mesa-dev mailing list