All of the bits appear to already be in place to support this in the
sampler (which the original AMD version didn't allow).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The extension is always supported if GLSL 1.30 is supported.
Softpipe and llvmpipe support is also added (trivial).
Radeon and nouveau support is already done.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Just happened to stumble across this registry key while debugging
something else.
This technique is much neater than trying to override opengl32.dll.
Also a few minors cleanups.
SCons is required for Windows. Add links to flex/bison for Windows.
Reorder items and improve formatting.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Both changes landed in 10.2, and for people not following the
development cycle these will come as a surprise. Note that the
pipe_* interface is not stable.
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Rob Clark <robclark@freedesktop.org>
relnotes weren't updated this whole time, so I went through all the
GL3.txt changes and picked out the nouveau ones since 10.1.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This extension is a huge grab-bag of "stuff that's in DX11". Break it
apart to make it clear what still needs to be done.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>
It is quite hard to meet the dependency of the libxml2 python bindings
outside Linux, and in particularly on MacOSX; whereas ElementTree is
part of Python's standard library. ElementTree is more limited than
libxml2: no DTD verification, defaults from DTD, or XInclude support,
but none of these limitations is serious enough to justify using
libxml2.
In fact, it was easier to refactor the code to use ElementTree than to
try to get libxml2 python bindings.
In the process, gl_item_factory class was refactored so that there is
one method for each kind of object to be created, as it simplifies
things substantially.
I confirmed that precisely the same output is generated for GL/GLX/GLES.
v2: Remove m4/ax_python_module.m4 as suggested by Matt Turner.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
It turns out we can allow COHERENT storage/mappings all the time,
regardless of LLC vs non-LLC. It just means never using temporary
mappings to avoid GPU stalls, and on non-LLC we have to use the GTT intead
of CPU mappings. If we were to use CPU maps on non-LLC (which might be
useful if apps end up using buffer_storage on PBO reads, to avoid WC read
slowness), those would be PERSISTENT but not COHERENT, but doing that
would require us driving the clflushes from userspace somehow.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
