Index | Thread | Search

From:
Jose Maldonado <josemald89@gmail.com>
Subject:
Re: Mesa, picom and glGetQueryObjectui64v symbol lost
To:
Jonathan Gray <jsg@jsg.id.au>
Cc:
tech@openbsd.org
Date:
Sat, 10 Feb 2024 18:23:21 -0400

Download raw body.

Thread
El Sat, 10 Feb 2024 12:53:14 +1100
Jonathan Gray <jsg@jsg.id.au> escribió:
> On Fri, Feb 09, 2024 at 12:12:49PM -0400, Jose Maldonado wrote:
> > Hello everyone!
> > 
> > I have been working on a patch to be able to build picom in its v11+
> > versions on OpenBSD. At the moment, the patches and solutions I have
> > work, but they depend on libepoxy in OpenBSD because the
> > glGetQueryObjectui64v function does not have a public symbol in
> > libGL, but libepoxy (epoxy_glGetQueryObjectui64v) does.
> > 
> > I've pushed a PR upstream, and we're looking for a solution, but
> > since they don't have a way to build test with OpenBSD, they can't
> > reliably test anything themselves. And what I have tried, it all
> > ends in the same point: libepoxy.
> > 
> > Despite this, I have a question: Why does Mesa on other systems
> > expose glGetQueryObjectui64v and OpenBSD's Mesa doesn't?
> 
> It could be libGL elsewhere isn't Mesa, but libglvnd or something from
> nvidia.
> 

Thanks for your response @jsg in this case, glGetQueryObjectui64v maybe
is expose by libglvnd in other OS. 

> > 
> > This behavior is strange, because if that symbol were exposed, we
> > could compile picom without major problems or code modifications.
> 
> I don't think it is supposed to be exposed directly, but only through
> something like glXGetProcAddress() as it depends on the context
> version.
> 

In my case, Mesa in OpenBSD --current give support for:

OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 580 Series (polaris10, LLVM
16.0.6, DRM 3.54, 7.4) OpenGL core profile version string: 4.6 (Core
Profile) Mesa 23.1.9 OpenGL core profile shading language version
string: 4.60 OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.1.9
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 23.1.9
OpenGL ES profile shading language version string: OpenGL ES GLSL ES
3.20 OpenGL ES profile extensions:

And what you say about the exposition explains many things, basically
it leads us to use solutions like libglvnd or libepoxy, to facilitate
access to said OpenGL functions.


> https://registry.khronos.org/OpenGL/extensions/ARB/ARB_timer_query.txt
> "This extension is written against the OpenGL 3.2 specification."
> 
> https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGetQueryObject.xhtml
> "glGetQueryObjecti64v and glGetQueryObjectui64v are available only if
> the GL version is 3.3 or greater."

I have sent some patches to upstream to resolve the compilation of
picom, and in the process it has been decided to add support for
libepoxy, which does offer us support for _epoxy_glGetQueryObjectui64v
directly in OpenBSD and is also fully compatible with the rest of the
OS where picom is builded.

Thanks for your response, @jsg I have learned a lot from this.

-- 
*********************************************************
Dios en su cielo, todo bien en la Tierra