| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
v2: Marek: rename tess spacing definitions
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
v2: Marek: rename shader types
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Changes generated by:
cd src/mapi/glapi/gen
for i in *.xml; do
cat $i |\
sed 's/[[:space:]]*offset="[^"]*">/>/' |\
sed 's/[[:space:]]*offset="[^"]*"[[:space:]]*$//' |\
sed 's/[[:space:]]*offset="[^"]*"[[:space:]]*/ /' > x
mv x $i
done
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Comparing the output of
nm -D libGL.so.349.16 | grep ' T gl[^X]' | sed 's/.* T //'
between Catalyst NVIDIA 349.16 and this commit, the only change is a bunch
of functions that NVIDIA exports that Mesa does not.
If a function is not statically exported by either of the major binary
drivers on Linux, there is almost zero chance that any application
statically links with it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Comparing the output of
nm -D arch/x86_64/usr/X11R6/lib64/fglrx/fglrx-libGL.so.1.2 |\
grep ' T gl[^X]' | sed 's/.* T //'
between Catalyst 14.6 Beta and this commit, the only change is a bunch
of functions that AMD exports that Mesa does not and some OpenGL ES
1.1 functions that Mesa exported but AMD does not.
The OpenGL ES 1.1 functions (e.g., glAlphaFuncx) are added by extensions
in desktop. Our infrastructure doesn't allow us to statically export a
function in one lib and not in another. The GLES1 conformance tests
expect to be able to link with these functions, so we have to export
them.
If a function is not statically exported by either of the major binary
drivers on Linux, there is almost zero chance that any application
statically links with it.
As a side note... I find it odd that AMD exports glTextureBarrierNV but
not glTextureBarrier.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Comparing the output of
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
between 10.3.7 and this commit, the only change is the removal of
glFramebufferTextureFaceARB. This function was removed a couple commits
previously.
glClipControl was, at the time 10.3 shipped, a very new function. It
was added by GL_ARB_clip_control. That extension was ratified by the
Khronos Board of Promoters on August 7, 2014. It's less than a year
old, and I don't think it's is likely that there are many applications
using that extension... much less statically linking with the function.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Comparing the output of
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
between 10.4.7 and this commit, the only change is the removal of
glFramebufferTextureFaceARB. This function was removed a couple commits
previously.
None of these functions are particuarly new. If applications were not
statically linking them with 10.4.7, there's approximately zero chance
they will for 10.6.
Almost all of these functions are for GL_ARB_direct_state_access.
Since the whole DSA API wasn't statically exported (and the extension
wasn't enabled!), I think there's exactly zero chance anyone linked
against these symbols.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Comparing the output of
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
between 10.5.5 and this commit, the only change is the removal of
glFramebufferTextureFaceARB. This function was removed a couple commits
previously.
None of these functions are particuarly new. If applications were not
statically linking them with 10.5.5, there's approximately zero chance
they will for 10.6.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
|
|
Changes generated by:
cd src/mapi/glapi/gen
for i in *.xml; do
cat $i |\
sed 's/[[:space:]]*static_dispatch="[^"]*">/>/' |\
sed 's/[[:space:]]*static_dispatch="[^"]*"[[:space:]]*$//' |\
sed 's/[[:space:]]*static_dispatch="[^"]*"[[:space:]]*/ /' > x
mv x $i
done
Comparing the output of
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
before and after this commit showed no differences.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
|
|
The set of functions with static dispatch is (supposed to be) defined by
the Linux OpenGL ABI. We export quite a few more functions than that
for historical reasons. However, this list should never grow.
This table is used instead of the static_dispatch tag in the XML to
generate the static dispatch functions. I used
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
before and after the change. diff showed no differences.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
|
|
Since the set of functions with static will never change, there is no
reason to store it in the XML. It's just one of those fields that
confuses people adding new functions.
This is split out from the rest of the series so that in-code assertions
can be used to verify that the data in the Python code matches the XML.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
|
|
Mesa does not (and probably never will) support GL_ARB_geometry_shader4,
so this function will never exist. Having a function that is
exec="skip" and offset="assign" is just weird.
There are still a couple 'exec="skip" offset="assign"' functions
remaining. These remain because we either support GLX protocol for them
(glSampleMaskSGIS and glSamplePatternSGIS) or older DRI drivers still
need them in the dispatch table (glResizeBuffersMESA). The SGIS
functions can be removed later.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Without this the next patch will try to put these functions in the
dispatch table in indirect_init.c.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
With DSA we can no longer rely on this being done in st_validate_state
in response to the framebuffer bindings having changed.
This fixes the ext_framebuffer_multisample-bitmap piglit test.
Signed-off-by: Fredrik Höglund <fredrik@kde.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Commit 3687d75 changed the fs_visitor constructors, but it didn't update
all the users. As a result, 'make check' fails.
I added the explicit cast to the gl_program* parameter to make it more
clear which NULL was which.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@Whitecape.org>
|
|
We also reduce the amount of need-to-know information about st_api
to require one less extern "C" in st_manager.h
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
For scalar GS support, we either need to add a fourth constructor which
takes the GS structures, or combine the existing two and pass the shader
stage.
Given that they're not significantly different, I opted for the latter.
v2: Remove more stuff from the .h file (Jason and Jordan).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
With earlier commit (7a58262e58d egl: Remove skeleton implementation of
EGL_MESA_screen_surface) we've removed the skeleton implementation of
eglCopyContextMESA(). Just like EGL_MESA_screen_surface this extension
was never implemented in mesa.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
The extension requires that the address of the core functions should be
available via eglGetProcAddress. Currently the list is guarded by
_EGL_GET_CORE_ADDRESSES, which was only set for the scons (windows)
build.
Unconditionally enable it for all the builds (automake, android and
haiku) considering that the extension is not platform specific and is
always enabled.
v2: Drop the _EGL_GET_CORE_ADDRESSES macro altogether.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
s/EGL_MESA_dma_buf_image_export/EGL_MESA_image_dma_buf_export as defined by the spec
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
|
|
The EGL 1.3, 1.4 and 1.5 spec (as quoted below) explicitly mentions that
providing static symbols for functions provided by EGL extensions is not
portable. Considering that relatively recently we've seen a non-mesa
desktop EGL implementation, the fact that we opt for such behaviour has
gone unnoticed.
From the EGL 1.5 specification:
For functions that are queryable with eglGetProcAddress,
implementations may choose to also export those functions
statically from the object libraries implementing those
functions. However, portable clients cannot rely on this
behavior.
To encourage devs against writing such non-portable code, let's hide the
symbols similar to the official binary driver from NVIDIA.
v2: Quote the EGL 1.5 spec, as suggested by Chad.
Cc: Brian Paul <brianp@vmware.com>
Cc: Chad Versace <chad.versace@intel.com>
Cc: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
|
|
Similar to other EGL extensions - guard the function prototypes by
EGL_EGLEXT_PROTOTYPES as the libEGL library does (should) not provide
the symbols statically.
Instead users should call eglGetProcAddress, which returns the function
pointer. The latter of which was missing the type declaration (typedef).
Cc: Dave Airlie <airlied@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
|
|
The driver search/load is not done at eglGetDisplay (or eglOpenDisplay
as the readme called it) time, but during eglInitialize().
Drop _eglMain (available only for external drivers) reference. Mention
we use function(s), specific to the built-in driver(s).
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
|
|
Cleanup the function propotypes which were part of the previous EGL
drivers.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
|
|
The only user (egl_gallium) is not longer around.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
|
|
This was causing corruption with hw binning on a306. Unlikely that it
is a306 specific, but rather the smaller gmem size resulted in different
tile configuration which was triggering the bug at certain resolutions.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Cc: "10.4" and "10.5" and "10.6" <mesa-stable@lists.freedesktop.org>
|
|
Whitelist adreno 306 (as found in msm8916/apq8016). Works pretty much
out of the box, although the smaller GMEM size requires more tiles to
fit 1920x1080, so bump up the max # of tiles as well.
Since it is just whitelist + trivial change, it makes sense to land on
all the active release branches.
Note that a305c ends up with gpu-id "306", hence a306 ends up with
gpu-id of "307". Apparently that is what happens when you let the
marketing dept name things.
Cc: "10.4" and "10.5" and "10.6" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
|
|
Reviewed-by: Brian Paul <brianp@vmware.com>
|
