| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Add mutual exclusion behavior to threading layer after reporting collisions.
This will allow applications to continue beyond first threading error.
It can't help reentrant calls.
|
|
Also add GetGlobalExtensionInfo to layer .def file
|
|
|
|
TODO: re-enable glave build, advance API for glave
v2: get rid of outdated code in tri introduced by rebase
rename wsi_null.c (olv)
|
|
This version should be able to find a key/value if it exists in either the 32
or 64 bit hive. Also, it also doesn't allocate any string data until it knows
what size is needed.
Changed the "xcv_nvidia.cpp" file to also use the new registry approach.
|
|
This change modifies many of the generators to use "#if
defined(PLATFORM_LINUX) || defined(XCB_NVIDIA)" to choose between using
XCB or WIN32 native.
|
|
These changes were cherry-picked from nvidia-dev-20150218 and
KhronosGroup/GDC-stable.
|
|
Instead, build layers with -Bsymbolic. This should fix (or hide) a reported
crash with overriden malloc()/free().
|
|
The loader on Windows now looks in the Windows Registry + in environment
variables for the following (Note the new names--"LIB" was dropped):
- XGL_DRIVERS_PATH
- XGL_LAYERS_PATH
- XGL_LAYER_NAMES
Linux still retains the "LIB" at the start of the environment variable names.
If both are used, they are concatenated into a semi-colon-delimited list.
A generic loader_get_registry_and_env() func is used to perform this (only for
Windows, since Linux doesn't have a registry).
|
|
This is a hopefully-temporary solution to prevent some of the problems of
people breaking the Windows build while developing on Linux (or vice-versa).
This uses macros of the names of Linux/Windows-specific functions in order to
catch people who use those functions directly, instead of using the
platform-compatibility-layer functions.
In order to avoid problems with the layers #include'ing "loader_platform.h"
before they #include system files (which can mess them up), I #include
"loader_platform.h" twice. The 2nd time, it #define's the hopefully-temporary
macros.
Note: For some reason, we can't #define LoadLibrary(). It generates warnings
on Windows.
|
|
|
|
The STATIC_INLINE macro is now in "xglPlatform.h". It is also now being used
by the *_loader_magic_value() functions. This allows it to be compiled on
Windows.
|
|
|
|
As part of this, eliminated some similar warnings within/across usage of
"loader_platform.h". One of these is #define'ing _CRT_SECURE_NO_WARNINGS, so
that VisualStudio won't issue warnings with our use of _snprint() (which they
don't consider secure enough; but their desired function doesn't match the
signature of snprintf()).
|
|
|
|
These directories build and are partially turned-on on Windows, using the "tri"
demo (follow-on commit) and a "NULL driver" that was created out of the
sample/Intel driver. The GetProcAddress() is not yet finding symbols in the
NULL driver.
For now:
- "C:\Windows\System32" is the default XGL driver directory. The getenv()
isn't yet working. I suggest creating your own #define in order to point to
where a driver is.
- In order to recognize a Windows driver, we must look at both its prefix and
suffix (i.e. it is named "XGL_*.dll", e.g. "XGL_i965.dll).
- We autogenerate Windows ".def" files for the layers. Additional info is:
- This is necessary in order for a DLL to export symbols that can be queried
using GetProcAddress(). We can't use the normal Windows approach of
declaring these functions using "__declspec(dllexport)", because these
functions are declared in "xgl.h".
- This involves adding and running the new "xgl-win-def-file-generate.py"
file.
- NOTE: Layers don't have the xglInitAndEnumerateGpus() entrypoint, just the
xglGetProcAddr() entrypoint (and now the xglEnumerateLayers() entrypoint).
Generating them is pretty simple.
NOTE: In order to build on a 64-bit Windows 7/8 system, I did the following:
- Install VisualStudio 2013 Professional
- Install CMake from: http://www.cmake.org/cmake/resources/software.html
- I let it add itself to the system PATH environment variable.
- Install Python 3 from: https://www.python.org/downloads
- I let it add itself to the system PATH environment variable.
- Obtain the Git repository, checkout the "ian-150127-WinBuild" branch.
- Using a Cygwin shell: I did the following:
- "cd" to the top-level directory (i.e. the one that contains the ".git"
directory).
- "mkdir _out64"
- "cd _out64"
- "cmake -G "Visual Studio 12 Win64" .."
- At this point, I used WindowsExplorer to open the "XGL.sln" file. I can
build. CMake causes the build shortcut to be "Ctrl-Shift-B" instead of the
normal "F7". I had to right-click the "ALL_BUILD" project, go to
Properties->Debugging and change the debug Command and Working Directory to
point to "tri.exe" and where the executable are. At this point, I can debug
(using the normal "F5" shortcut).
|
