The new GL registry XML contains the 'glsc2' identifier for the OpenGL
SC 2.0 API. We can safely ignore it, since we don't really know what to
do with it, at the moment.
To avoid a symbols file on Windows, Epoxy annotates all the publicly
visible symbols directly in the source, but uses the default symbol
visibility everywhere else. This means that only some symbols are
annotated as `EPOXY_IMPORTEXPORT`, and generally only on Windows.
Additionally, Epoxy has a private 'PUBLIC' pre-processor macro for
internal use, which duplicates the `EPOXY_IMPORTEXPORT` but contains
more logic to detect GCC, in case we're building with GCC on Windows.
This would be enough, except that EGL is also available on Windows,
which means we'd have to annotate the exported `epoxy_*` API inside
epoxy/egl.h as well. At that point, though, we should probably avoid
any confusion, and adopt a single symbol visibility policy across the
board.
This requires some surgery of the generated and common dispatch sources,
but cuts down the overall complexity:
- there is only one annotation, `EPOXY_PUBLIC`, used everywhere
- the annotation detection is done at Epoxy configuration time
- only annotated symbols are public, on every platform
- annotated symbols are immediately visible from the header
Instead of using a generator and having to deal with tweaking the
inclusion paths, we can use a custom target rule, which will do the
right thing and put the generate files where we expect them to be.
Due to how Meson and Ninja work we need to be a bit more careful as to
how we deal with dependencies and generated files, especially since
Epoxy is built on the assumption that the only inclusion path for the
headers lies under the 'include' sub-directory.
First of all, we need to split the dispatch table generation into two
separate steps, one for the headers and one for the source files.
Additionally, we need to munge the paths of the non-generated headers
so that we reference them by their correct path.
These changes are necessary to ensure that Epoxy can be built on a
system without Epoxy installed already; the previous Meson-based build
system relied on the headers being installed in a system directory.
The gen_dispatch.py script relies on the source and include directories
to exist before dumping the files in there, split by type, in order to
sustain the split of the headers existing in a separate root from the
source files. This causes a spooky-action-at-a-distance scenario where
headers are generated by rules inside the source directory but influence
the contents of a separate directory — and require a separate set of
rules to install those headers.
Different build systems would require either splitting the generation in
to two separate passes (which is more expensive and time consuming), or
generate the header and source files in the same directory, and just
tweak the inclusion paths accordingly.
Since we want to maintain this fiction for the autotools build, but
ignore it for different build systems, let's add a separate set of
arguments for gen_dispatch.py that make the rules inside Makefile.am
work appropriately.
Define PACKED for Visual Studio builds, so that we can try to reduce
our library size for Visual Studio builds. Add a ENDPACKED macro
that is currently defined only for Visual Studio builds as packing is
done via __pragma(pack(push,n), that should be popped when done.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
...so that the generated code are buildable by pre-2013 Visual Studio.
The main thing that this does is that we avoid named initializers, but
instead initialize the structs in old-school C89 way.
The generated code may not look that robust, but since this is generated
code, I think this is not that much an issue; when the Khronos registry gets
updated, all that is needed is that the code gets re-generated, and we have the
items in the right order.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Most of the changes that happened after commit 8bbc0d40 broke epoxy
pretty much irreparably because of the CMake build and the attempt at
making libepoxy a static library that can be copy-pasted into another
project without generating files.
Since all the commits are entangled, and are full of unrelated changes,
we cannot simply do a localized set of reverts; instead, we need to hit
the reset button.
From this point forward, we're going to improve libepoxy's build while
attempting to keep the existing build system working. This may mean
reinstating the CMake build system at a later date.
...so that the generated code are buildable by pre-2013 Visual Studio.
The main thing that this does is that we avoid named initializers, but
instead initialize the structs in old-school C89 way.
The generated code may not look that robust, but since this is generated
code, I think this is not that much an issue; when the Khronos registry gets
updated, all that is needed is that the code gets re-generated, and we have the
items in the right order.
Since our provider enums are small, we can store them as bytes or
shorts if we just let the compiler know that it's OK. Saves 20kb in
the compiled library.
This updates the script to generate code that is buildable by Visual Studio
2013 by:
-Using a macro to define the compiler-specific way to do noinline for a
function, and use it when needed.
-Avoid using empty arrays and structs as that is a C99 feature that will
likely be never support on Visual Studio as it is now an optional feature
of C11.
Without this, we got code generation that was dependent on the
original ordering in the hash table, and thus non-reproducible builds.
Based on a commit by Stephan Kulow, but retaining the sorting by
function name first (that way all providers with the same name appear
next to each other like before, and also happens to ensure that core
names tend to appear before non-core names)
This increases the size of the library, but avoids some of the
concerns that have been brought up with the library silently switching
you from glWhateverEXT() to glWhatever() if there might be slight
behavior differences between the two that hadn't been identified. The
downside is that it means we can't share the resolver functions among aliases.
One of the problems with krhplatform.h (besides it being a terrible
idea in the first place) is that it's not present on many systems at
all, including apple, win32, and linux before late 2009.
So, unless we introduce the first ./configure dependency to the core
library build, we really do need to define these standard types to
their standard values. But if we allow khrplatform.h inclusion as
well, we'll get long-vs-int redefinition warnings on 32-bit. So, we
have to completely replicate the header, which is a thing we've done
for everything else except for eglplatform.h.
A testcase will be used to make sure that our types don't drift from
the system khrplatform.h types, if it even exists.
Fixes#17
For performance, I want to be able to make single-context (well,
single-pixel-format-and-device) apps be able to directly call GL
functions through function pointers. Bake that into the ABI now so I
can get a release out the door and fix this up later.
This also fixes the lack of __stdcall annotation on the
PFNWHATEVERPROC typedefs.
This lets the compiler generate faster function calls (call through
function pointer, instead of call into a linker-generated stub func
containing jump to function pointer).
For example, on desktop 2.1 GL on Apple, there's no glBindVertexArray,
but there is glBindVertexArrayAPPLE, and as far as a caller is
concerned, the APPLE variant should be able to stand in for the
core/ARB version. Similarly for trying to do FBOs on an old Mesa
implementation that didn't have ARB_fbo yet, but did have EXT_fbo.
In addition to the failing testcase, there were a couple of
regressions in piglit's attribs test: one from glBegin_unwrapped vs
glBegin confusion in the __asm__ directives we were generating, and
one where the function pointers apparently were just getting mixed up
at application runtime.
These tell the linker to generate GNU_IFUNC relocs that rewrite the
PLT entries in the user's address space to point to our resolved GL
function, so there's no extra function pointer. It also, as a bonus,
cuts 400k out of the library.
This requires a toolchain from 2010 or so. Unfortunately, it's going
to take a bit more investigation to find out what specific bits are
required.
Fixes#4
Emmanuele Bassi
Chun-wei Fan
Simon Parzer
Daniel Wolf
Yaron Cohen-Tal
Eric Anholt