Rasterizer core only supports polygonmode front==back. Add logic for
populating fillMode for the rasterizer only for that case correctly.
Provide enum conversion between mesa enums and core enums.
The core renders lines/points as tris. Previously, code would enable
stipple for polygonmode != FILL. Modify stipple enable logic so that
this works correctly.
No regressions in vtk tests.
Fixes the following piglit tests:
pointsprite
gl-1.0-edgeflag-const
v2: remove cc stable, and remove "not implemented" assert
v3: modified commit message
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Add support for polygonmode point in the binner. This is done by
splitting BinPostSetupPoints from BinPoints, so the earlier call can be
called from BinTriangles. Setup has already been done at the time
BinPostSetupPoints needs to be called.
This checkin just adds support in the rasterizer. A separate checkin
will add the appropriate driver support.
v2: remove cc stable
v3: modified commit message and subject line
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
v3: list piglit tests fixed by this patch. Fixed typo Tim pointed out.
v2: Reword commit message to more closely adhere to community
guidelines.
This patch moves msaa resolve down into core/StoreTiles where the
surface format conversion routines are available. The previous
"experimental" resolve was limited to 8-bit unsigned render targets.
This fixes a number of piglit msaa tests by adding resolve support for
all the render target formats we support.
Specifically:
layered-rendering/gl-layer-render: fail->pass
layered-rendering/gl-layer-render-storage: fail->pass
multisample-formats *[2,4,8,16] gl_arb_texture_rg: crash->pass
multisample-formats *[2,4,8,16] gl_ext_texture_snorm: crash->pass
multisample-formats *[2,4,8,16] gl_arb_texture_float: fail->pass
multisample-formats *[2,4,8,16] gl_arb_texture_rg-float: fail->pass
MSAA is still disabled by default, but can be enabled with
"export SWR_MSAA_MAX_COUNT=4" (1,2,4,8,16 are options)
The default is 0, which is disabled.
This patch improves the number of multisample-formats supported by swr,
and fixes several crashes currently in the 17.1 branch. Therefore, it
should be considered for inclusion in the 17.1 stable release. Being
disabled by default, it poses no risk to most users of swr.
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
cc: mesa-stable@lists.freedesktop.org
Make it a bit clearer that the index spaces are logically seperate by
having them defined in different functions.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Limiting LS-HS to a single wave is required on all SI chips due to an
issue with a power management feature.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
In a VS->TCS->TES->PS pipeline, the primitive ID is read from TES exports,
so it is as if TES were using the primitive ID.
Specifically, this fixes a bug where the primitive ID is not reset at
the start of a new instance.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
There are a bunch of piglit fast clear tests that regressed on SI, for
example ./bin/ext_framebuffer_multisample-fast-clear single-sample.
The problem is that a texture is bound as a framebuffer, cleared, and
then rendered from in a loop that loops through different clear colors.
The texture is never rebound during all this, so the change to
tex->dirty_level_mask during fast clear was not taken into account
when checking for compressed textures.
I have considered simply reverting the problematic commit. However,
I think this solution is better. It does require looping through all
bound textures after a fast clear, but the alternative would require
visiting more textures needless on every draw. Draws are much more
common than clears.
Note that the rendering feedback loop rules do not apply here, because
the framebuffer binding is changed between the glClear and the draw
that samples from the texture that was cleared.
Fixes: bdd6449769 ("radeonsi: don't mark non-dirty textures with CMASK as compressed")
Cc: 17.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This code was merged commented out, and has stayed that way ever since.
Signed-off-by: Pierre Moreau <pierre.morrow@free.fr>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This reverts commit 7088b655e8.
It breaks performance counters. If you use them with this commit, they hang
the machine hard. Sysrq and ssh don't work.
Possibly other gen's have a similar limit. Fixes glmark2 -b shadow
with larger resolutions on devices with small gmem (for example,
fullscreen 1080p on 8x16/db410c).
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Rob Clark <robdclark@gmail.com>
Fixes: 7088b655e8 ("radeonsi: constify a bunch of the perfcounter structs.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100937
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Picked from a different branch. When we stop using the scratch patching,
this function will not be called.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
LLVM 3.8:
- had broken indirect resource indexing
- didn't have scratch coalescing
- was the last user of problematic v16i8
- only supported OpenGL 4.1
This leaves us with LLVM 3.9 and LLVM 4.0 support for Mesa 17.2.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
To simplify things for now, since all the gfx shader stages share a
single SSBO state block, only advertise SSBO support for fragment shader
(and compute when we have that). We could possibly use a fixed-
partitioning of the SSBO index space to support SSBOs on other stages
without having to resort to shader variants.
Signed-off-by: Rob Clark <robdclark@gmail.com>
TODO cwabbott pointed out a write-after-read hazzard, which effects both
this and arrays. A write needs to depend on *all* reads since the last
write, not just the last read.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Always true, since the dri modules required shared glapi.
With earlier commit (da410e6afa "configure: explicitly require shared
glapi for enable-dri") we even made that explicit during the configure
stage.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
In the early days of Xorg and Mesa we had multiple providers of the
GLAPI. All of those were the ones responsible for dlopening the DRI
module. Hence it was perfectly fine, and actually expected, for the DRI
modules to have unresolved symbols.
Since then we've moved the API to a separate shared library and no other
libraries provide the symbols.
Here comes the picky part:
It's possible that one uses old Xorg (where libglx.so provides the
GLAPI) and new Mesa (with DRI modules linking against libglapi.so).
That should still work, since the the libglx.so symbols will take
precedence over the libglapi.so ones.
I've verified this while running 1.14 series Xorg alongside this (and
next) patch.
It may seem a bit fragile, but that's of reasonably OK since all of the
affected Xorg versions have been EOL for years.
The final one being the 1.14 series, which saw its final bug fix release
1.14.7 in June 2014.
To ensure that the binaries do not have unresolved symbols add
-no-undefined and $(LD_NO_UNDEFINED), just like we do everywhere else
throughout mesa.
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98428
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This moves the structs from the data segment to the rodata segment,
which seems like the more correct place for them.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No piglit regressions.
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
