Just to make it consistent with the rest of vbo, since it would
be an exported symbol anyways.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No users outside this file.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No reason for this to be global from what I can see
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These aren't used outside thie file from what I can see.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I can't see any external users, and this is a global symbol,
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this array doesn't look like it needs to be global or unconst.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The current code is duplicated in two places and relies on `uname` to
detect the flags. This is no good for cross-compiling, and the current
logic uses -m64 for the x32 ABI which breaks things.
Unify the code in one place, avoid `uname` completely, and add support
for the new x32 ABI.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This symbol with dricore escapes into the namespace, its too generic,
we should prefix it with something just to be nice.
Should be applied to stable + 9.0
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
So glcpp tried to workaround yylex its own way, but failed,
do it properly.
This fixes another crash found after fixing the first crash.
this is a candidate for 9.0 and stable branches
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This avoids us making a global yylex symbol which will interfere will
all sorts of apps.
with libdricore which can't do symbol visibility currently we pollute
the namespace with this.
This is a candidate for 9.0 & stable branches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In commit 055093e (meta: remove call to _meta_in_progress(), fix
multisample enable/disable), we created a meta_set_enable() function
that could be used by meta ops to enable and disable GL_MULTISAMPLE
even when the GLES API was in use (the GLES API doesn't support
GL_MULTISAMPLE; it behaves as if it is always enabled). This created
some unfortunate code duplication between meta_set_enable() and the
existing _mesa_set_enable() function.
This patch eliminates the duplication by creating a
_mesa_set_multisample() function, which is used by both meta ops and
_mesa_set_enable() to enable/disable GL_MULTISAMPLE.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl version of _mesa_meta_GenerateMipmap() would require separate
shaders for glsl 120 and 130.
V2: Removed the code for integer textures as ARB is planning to
disallow automatic mipmap generation for integer textures.
NOTE: This is a candidate for stable branches.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
glsl path of _mesa_meta_GenerateMipmap() function would require different fragment
shaders depending on the texture target. This patch adds the code to generate
appropriate fragment shader programs at run time.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=54296
V2: Removed the code for integer textures as ARB is planning to
disallow automatic mipmap generation for integer textures.
Now using ralloc_asprintf in setup_glsl_generate_mipmap().
NOTE: This is a candidate for stable branches.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Gets VDPAUs shaders working again.
Signed-off-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Seems to have an affect on the allowable range of
values. Set evergreen+ to 1/256 to match 6xx/7xx.
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54877
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
v2: Group vgt register together to avoid lockup
v3: Split multi primitive register and index bias register
v4: Bump R600_NUM_ATOMS
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Oliver McFadden
Dave Airlie
Mike Frysinger
Dave Airlie
Paul Berry
Anuj Phogat
Christian König
Marek Olšák
Alex Deucher