On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote: > Steve Langasek <vorlon@debian.org> writes: > > Long ago I heard rumors of development work on mesa that would allow it to > > function as a proxy library, so that apps would link against libGL as needed > > and the GL implementation would use a hardware-accelerated GLES driver where > > possible, falling back to software GL where necessary. > This seems unlikely -- I believe GLES and GL have different semantics in > a few places which makes implementing GL on GLES inefficient; mostly > that GLES is missing stuff that GL applications often use, but I think > there are places where GLES is just different, including in how GLSL > works. Perhaps that explains why no one ever actually succeeded in implementing it, then? Thanks for the context. > I haven't tried, but I would expect that applications could use both GL > and GLES APIs at the same time, even to the same window. If this does > work with Mesa, then linking Qt against GLES wouldn't restrict > applications using free drivers at least? My recollection is that this becomes a practical problem of applications that want to use both Qt and GL being unbuildable due to namespace collisions at build time. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature