The storage was once used by get_sampler_uniform_value() but that
was fixed long ago to use the uniform storage assigned by the
linker.
By not assigning storage for images/samplers the constant buffer
for gallium drivers will be reduced which could result in small
perf improvements.
V2: rebase on ARB_bindless_texture
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
We shouldn't use the wide line stage if the line width is 1.
This check isn't strictly needed because all drivers are (now)
specifying a line wide threshold of at least 1.0 pixels, but
let's play it safe.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
The line stipple fallback code for virtual HW version 8 didn't work.
With HW version 8, we were getting zero when querying the max line
widths (AA and non-AA). This means we were setting the draw module's
wide line threshold to zero. This caused the wide line stage to always
get enabled. That caused the line stipple module to fall because the
wide line stage was clobbering the rasterization state with a state
object setting the line stipple pattern to 0xffff.
Now the wide_lines variable in draw's validate_pipeline() will not
be incorrectly set.
Also improve debug output.
BTW, also this fixes several other piglit tests: polygon-mode,
primitive- restart-draw-mode, and line-flat-clip-color since they
all use the draw module fallback.
See VMware bug 1895811.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
The SCons build has been using 10 digits of the git hash id for the
MESA_GIT_SHA1 string in git_sha1.h for about a year now. I bumped it
up after running into a case where a 7-digit hash ID was ambiguous.
This patch makes the same change for the autotools build.
The command "git log | grep "^commit" | cut -b 8-14 | sort | uniq -d"
shows there are currently 17 cases where 7 digits of hash id are
ambiguous on master (probably quite a few more if we'd consider other
branches).
Instead of using "git log -n 1 --oneline" use
"git rev-parse --short=10 HEAD" to get the HEAD hash id.
v2: use printf instead of sed, per Eric's suggestion.
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
This follows the model of imx (display) and etnaviv (render): pl111 is a
display-only device, so when asked to do GL for it, we see if we have a
vc4 renderer, make the vc4 screen, and have vc4 call back to pl111 to do
scanout allocations.
The difference from etnaviv is that we share the same BO between vc4 and
pl111, rather than having a vc4 bo and a pl11 bo and copies between the
two. The only mismatch between their requirements is that vc4 requires
4-pixel (at 32bpp) stride alignment, while pl111 requires that stride
match width. The kernel will reject any modesets to an incorrect stride,
so the 3D driver doesn't need to worry about that.
v2: Rebase on Android rework, drop unused include.
v3: Fix another Android bug, from Rob Herring's build-testing.
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Note that for requests for Prime FDs or flink names, we return handles to
the etanviv BO, not the scanout BO. This is at least better than previous
behavior of returning GEM handles for a request for an FD or flink name.
And add an assert that renderonly_get_handle is only used for getting the
GEM handle.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
The rules to generate egd_tables.h are added in Android makefile
Fixes: f42fb00 "r600/eg: add support for tracing IBs after a hang."
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Adds libmesa_git_sha1 static (dummy) library to generate git_sha1.h
with some polishing to header dependency on .git/HEAD and scripted rules.
The now redundant generation rules are removed from Android.gen.mk
libmesa_git_sha1 whole static depedency is added to libmesa_pipe_svga,
libmesa_dricore and libmesa_st_mesa modules
Fixes the following building error:
external/mesa/src/gallium/drivers/svga/svga_screen.c:26:10:
fatal error: 'git_sha1.h' file not found
^
1 error generated.
Fixes: 1ce3a27 ("svga: Add the ability to log messages to
vmware.log on the host.")
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
We were not considering as multiple fixes lines with:
Fixes: $sha_1, Fixes: $sha_2
Now, we split the lines so we will consider them individually, as in:
Fixes: $sha_1,
Fixes: $sha_2
Additionally, we try to get the SHA from split lines so:
Fixes:
$sha_1
Will be considered as:
Fixes: $sha_1
v2:
- Treat empty spaces earlier in fix lines (Emil)
- Fold 2 lines into one to gather fix commit ids (Emil)
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Emil Velikov <emli.velikov@collabora.com>
We were parsing the whole diff, although the candidates were
identified only by the commit message.
Now, we only use the commit message for parsing.
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Emil Velikov <emli.velikov@collabora.com>
This implements a way to import FDs with modifiers on plain GBM devices,
without the need to go through EGL. This is mostly to the benefit of
gbm_gralloc, which can keep its dependencies low.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This allows to import an FD with an explicit modifier passed through
userspace protocols.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
We tend to use the sources, as opposed to EXTRA_DIST to include the
headers.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Juan A. Suarez Romero <jasuarez@igalia.com>
It calling itself recursively prevented it from being inlined, resulting
in a copy being generated in every compilation unit referencing it. This
bloated the text segment of the Gallium mega-driver *_dri.so by ~4%,
and might also have impacted performance.
Fixes: ecd6fce261 ("mesa/st: support lowering multi-planar YUV")
v2:
* Add comment above pipe_resource_next_reference [Samuel Pitoiset]
v3:
* Use loop to unreference the full chain of resources referenced via
the next members [Timothy Arceri]
v4:
* Stop chasing ->next chain at the first sub-resource which isn't
destroyed [Nicolai Hähnle]
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
ISL already has all of the complexity required to figure out the correct
surface pitch and size taking tile alignment into account. When we get
a surface out of ISL, the pitch and size are already correct and using
brw_bo_alloc_tiled_2d doesn't actually gain us anything other than extra
asserts we have to do in order to ensure that the bufmgr code and ISL
agree. This new helper doesn't try to be smart but just allocates the
BO you ask for and sets up the tiling.
Reviewed-by: Plamena Manolova <plamena.manolova@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Before, we weren't setting step rate so we got whatever old value
happened to be lying around. This can lead to some interesting
rendering errors. In particular, if you run the OpenGL ES CTS with
dEQP-GLES3.functional.instanced.types.mat2x4 immediately followed by one
of the dEQP-GLES3.functional.transform_feedback.* tests, the transform
feedback test gets stale instancing data from the other test and fails.
The only thing that is causing this to not be a problem today is that we
use meta for clears and meta is setting up vertex buffers via the VBO or
non-interleaved path and setting step_rate to 0 for us. When blorp
depth/stencil clears are enabled, meta is no longer sitting between the
two tests and the stale data starts causing noticeable problems.
Cc: "17.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Instance divisor is a property of the vertex buffer and not the vertex
element so if we ever see anything other than 0, bail.
Cc: "17.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
On gen5-6, SeparateStencilBufferEnable and HierarchicalDepthBufferEnable
come hand in hand and we have to set either both or neither.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
This ensures that we get the correct layout for all stencil buffers, not
just those which are created as separate stencil for a depth buffer.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
The CL CTS queries the max allocation size, and then attempts to
allocate buffers of that size. If not enough contiguous RAM/VRAM is
available, this causes errors in the radeon kernel module due to
inability to allocate the required memory.
It's a bit of a hack, but experimentally on my system, I can use ~3/4
of the card's VRAM for a single global/constant buffer allocation given
current GUI/compositor use.
For a 1GB Pitcairn (HD7850) this gets me from the reported clinfo values of:
Global memory size 2143076352 (1.996GiB)
Max memory allocation 1500153446 (1.397GiB)
Max constant buffer size 1500153446 (1.397GiB)
To:
Global memory size 2143076352 (1.996GiB)
Max memory allocation 751619276 (716MiB)
Max constant buffer size 751619276 (716MiB)
Fixes: OpenCL CTS test/conformance/api/min_max_mem_alloc_size,
OpenCL CTS test/conformance/api/min_max_constant_buffer_size
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This updates the Gen4-5 code to use a line end cap width of 0.5
for non-smooth lines, and 1.0 for smooth lines - which is what we
do on Gen6+.
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
This unifies the Gen4-5 and Gen6+ line width calculations.
I believe it also fixes a bug - we weren't rounding the line width
to the nearest integer. The GL 4.5 (and GL 2.1) specs "Wide Lines"
section says:
"The actual width of non-antialiased lines is determined by rounding
the supplied width to the nearest integer, then clamping it to the
implementation-dependent maximum non-antialiased line width."
We don't need to care about _NEW_MULTISAMPLE here because multisampling
doesn't exist on Gen4-5, so the state shouldn't change.
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
This effectively reverts Robert Ellison's 2009 commit
cc8afbd386.
I'm not seeing any GL spec text indicating that UPPER won't work.
On Gen6+, this bit moved to 3DSTATE_WM as a single bit, controlling
UPPER_LEFT vs. UPPER_RIGHT. There is no way to request LOWER_RIGHT,
so UPPER_RIGHT is the best you can do.
In the G45 docs, it's marked as "Reserved" as well, but we just
decided to use it anyway.
This patch unifies the behavior between Gen4-5 and Gen6+.
Note that this is separate from point sprite texcoord behavior.
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Modern GL specifications say that the point size should be 1.0 when
gl_PointSize is unwritten and the last enabled stage is a geometry
or tessellation shader. If it's a vertex shader, though, both the
GL specs and ES 3.0 spec say that it's undefined - so since Gen4-5
only support vertex shaders, there's no actual requirement to do this.
Since there is a cost associated (an extra dirty bit, which may cause
SF_STATE to be emitted more often), it may not be a good idea.
The real benefit is that it makes all generations behave identically.
And that seems somewhat nice...
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
Apparently, Nanhai made the Gen4-5 point size calculations round to the
nearest integer in commit 8d5231a358,
"according to spec". When Eric first ported the driver to Sandybridge,
he did not implement this rounding.
In the GL 2.1 and 3.0 specs "Basic Point Rasterization" section, it does
say "If antialiasing and point sprites are disabled, the actual width is
determined by rounding the supplied width to the nearest integer, then
clamping it to the implementation-dependent maximum non-antialised point
width."
In contrast, GL 3.1 and later do not appear to contain this rounding.
It might be reasonable to round, given that we only implement GL 2.1.
Of course, if we were to do that, we should actually implement the AA
vs. non-AA distinction. Brian added an XXX comment reminding us to fix
this 10 years ago, but it never happened.
I think a better plan is to follow the newer, unrounded behavior. This
is what we do on Gen6+ and it passes all the relevant conformance tests.
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
According to the docs, a simple CS stall is insufficient to ensure that
the memory from the flush is visible and an end-of-pipe sync is needed.
Cc: "17.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2 (Jason Ekstrand):
- Take a flags parameter to control the flushes
- Refactoring
Cc: "17.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These two functions contain almost identical logic except for one SNB
workaround required for render target cache flushes. They may as well
call into the same code so we only have to handle the work-arounds in
one place.
Cc: "17.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
It's a 64-bit value. Splitting it up just makes the function arguments
awkward.
Cc: "17.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I forgot to add this when introducing the new key field. It doesn't
happen often - just with the Unigine workarounds. But we may as well
have it, so we get an accurate picture of why recompiles happen.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
KHR/khrplatform.h is required by the EGL, GLES and VG headers, but is
only installed if Mesa3d is compiled with EGL support.
This patch installs this header file unconditionally.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77240
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
wpos_tex used to be a GLuint so assigning -1 to it and
later comparing with -1 worked correctly, but commit
c349031c27 ("i915: Fix texcoord vs. varying collision in
fragment programs") changed wpos_tex to uint8_t and hence
broke the comparison. To fix this define a more explicit
invalid value for wpos_tex.
gcc warns us:
i915_fragprog.c:1255:57: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if (inputsRead & VARYING_BITS_TEX_ANY || p->wpos_tex != -1) {
^
And clang says:
i915_fragprog.c:1255:57: warning: comparison of constant -1 with expression of type 'uint8_t' (aka 'unsigned char') is always true [-Wtautological-constant-out-of-range-compare]
if (inputsRead & VARYING_BITS_TEX_ANY || p->wpos_tex != -1) {
~~~~~~~~~~~ ^ ~~
Cc: Chih-Wei Huang <cwhuang@android-x86.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Ian Romanick <ian.d.romanick@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Fixes: c349031c27 ("i915: Fix texcoord vs. varying collision in fragment programs")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This should fix compilation errors in some situations.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101418
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Timothy Arceri
Robert Foss
Brian Paul
Eric Anholt
Mauro Rossi
Andres Gomez
Samuel Pitoiset
Lucas Stach
Emil Velikov
Michel Dänzer
Jason Ekstrand
Aaron Watry
Kenneth Graunke
Topi Pohjolainen
Eric Le Bihan
Ville Syrjälä