| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
|
|
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This extension is identical to NV_texture_barrier. Alias
glTextureBarrier to the existing glTextureBarrierNV and use the existing
NV_texture_barrier extension bit.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Requires Evergreen/Cayman
Signed-off-by: Glenn Kennard <[email protected]>
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
This matches the name of the dd hook. Also convert a couple of nearby
dd implementations to lowercase + underscore as is now the standard.
Signed-off-by: Kristian Høgsberg <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Right now we decide which kernels to use and the GRF start offsets in
one place and emit the kernel pointers later. The logic of how to map
8, 16 and 32 kernels to kernel start pointers follows the same logic as which
GRF start offsets to use, so lets figure out these two things in one place.
Signed-off-by: Kristian Høgsberg <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
|
|
| |
Passes all piglit tests.
v2: rebased
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
This maintains a list of all TBOs in a pipe_context.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
| |
This fixes piglit spec/ARB_texture_buffer_object/data-sync.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Somebody forgot to do this. It was uncovered by recent st/mesa changes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82139
Cc: [email protected]
Reviewed-by: Alex Deucher <[email protected]>
Tested-by: Andreas Boll <[email protected]>
|
|
|
|
| |
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The EGL_EXT_image_dma_buf_import specification was revised (according to
its revision history) on Dec 5th, 2013, for EGL to not take ownership of
the file descriptors.
Do not close the file descriptors passed in to eglCreateImageKHR with
EGL_LINUX_DMA_BUF_EXT target.
It is assumed, that the drivers, which ultimately process the file
descriptors, do not close or modify them in any way either. This avoids
the need to dup(), as it seems we would only need to just close the
dup'd file descriptors right after.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76188
Signed-off-by: Pekka Paalanen <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gcc 4.6.3 chokes with the following error:
brw_vec4.cpp: In member function 'int brw::vec4_visitor::setup_uniforms(int)':
brw_vec4.cpp:1496:37: error: expected primary-expression before '.' token
Apparently C++ does not do named initializers for unions, except maybe
as a gcc extension, which is not present here.
As .f is the first element of the union, just drop it. Fixes the build
error.
Signed-off-by: Pekka Paalanen <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Fixes Khronos GLES3 CTS test:
dynamic_expression_array_access_vertex
Cc: <[email protected]>
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82574
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
| |
Trivial.
|
|
|
|
| |
Trivial.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* --enable-{32,64}-bit is done. Use --build and --host instead.
* Configure does not add "-g -O2" to C{,XX}FLAGS.
* Pkg-config has been mandatory for a while now.
* Avoid using LDFLAGS, refer to pkg-config.
* --with-expat is deprecated. Use pkg-config.
v2:
* Note that CC/CXX will need to be set for multilib builds.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]> (v1)
|
|
|
|
|
|
|
|
|
|
| |
The SCons documentation is not explicit on the topic yet building mesa
with SCons and MSVC is known to have problems when headers are listed.
So be safe just drop them for now.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82534
Tested-by: Vinson Lee <[email protected]>
Acked-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two were added ages ago, with an explicit comment "Hacks ..."
They have been insufficient for years and maintainers needed to
explicitly handle the build themselves.
Rather than lying and pretending that it works, just kill this hack and
let maintainers build things the way it should be done for their
distribution.
Document the removal in the release notes.
Suggested-by: Ilia Mirkin <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 2af28040d639dddbb7c258981a00eaf3dfcbcf03.
The commit was resolving an issue where libtool will not setup the
environment correctly when one explicitly provides --enable-{32,64}-bit
at configure time. It was caused due to the "-m32,64" C{,XX}FLAGS being
set too late relative to LT_INIT.
At the same time this cases the enable_static to be incorrectly set,
amongst others leading to build issues. Rather than being smart and
trying to handle 32/64 bit build ourselves it may be better to delegate
it to the builder/maintainer. The latter should now know better which is
the correct(most appropriate) method.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82536
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82546
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Tested-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The brw_stage_prog_data struct previously contained an array of float pointers
to the values of parameters. These were then copied into a batch buffer to
upload the values using a regular assignment. However the float values were
also being overloaded to store integer values for integer uniforms. This can
break if x87 floating-point registers are used to do the assignment because
the fst instruction tries to fix up invalid float values. If an integer
constant happened to look like an invalid float value then it would get
altered when it was copied into the batch buffer.
This patch changes the pointers to be gl_constant_value instead so that the
assignment should end up copying without any alteration. This also makes it
more obvious that the values being stored here are overloaded for multiple
types.
There are some static asserts where the values are uploaded to ensure that the
size of gl_constant_value is the same as a float.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81150
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This fixes an issue with flash where it tries to destroy a decoder
after already destroying the device associated with the decoder.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82517
Signed-off-by: Christian König <[email protected]>
Acked-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Requires GLSL 1.50 or higher, which we only support in the core profile.
V2: Fix broken alignment
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
| |
Fixes the LUMINANCE_ALPHA formats of fbo-clear-formats piglit test.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
All we need to do is decompose this to two SIMD8 instructions, like we
do in many other cases. We even already have code for that.
I apparently just botched this last time I tried, and it was easy.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
When dual source blending, the visitor already stores a flag in
brw_wm_prog_data (dual_src_blend) for the state upload code to use.
The generator also receives this, so there's no need to pass an
additional flag.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
The _mesa_swizzle_and_convert path can't do transfer ops, so we should bail
if they're needed.
Signed-off-by: Jason Ekstrand <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
| |
I started this as well on top of my fp64 stuff.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This just cherry-pick the extensions into a list for GLES 3.1
I'm not actually sure if this list if complete or correct, maybe someone
else can tell me what I missed, and I'm not 100% sure on multi_draw_indirect.
Reviewed-by: Matt Turner <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==17630== Invalid read of size 4
==17630== at 0x400AE10: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==17630== by 0x49024A2: u_upload_data (u_upload_mgr.c:253)
==17630== by 0x49050E1: u_vbuf_draw_vbo (u_vbuf.c:980)
==17630== by 0x487DE29: cso_draw_vbo (cso_context.c:1425)
==17630== by 0x487DEA0: cso_draw_arrays (cso_context.c:1445)
==17630== by 0x48A3B0E: hud_draw_colored_prims.constprop.6 (hud_context.c:123)
==17630== by 0x48A4810: hud_draw (hud_context.c:266)
==17630== by 0x48763F7: dri_flush (dri_drawable.c:483)
==17630== by 0x4057510: dri2Flush.constprop.4 (dri2_glx.c:559)
==17630== by 0x405789E: dri2SwapBuffers (dri2_glx.c:851)
==17630== by 0x402C531: glXSwapBuffers (glxcmds.c:842)
==17630== by 0x8049716: ??? (in /usr/bin/glxgears)
==17630== Address 0x4426b2c is 4 bytes after a block of size 1,008 alloc'd
==17630== at 0x4006B11: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==17630== by 0x48A4CE7: hud_pane_add_graph (hud_context.c:625)
==17630== by 0x48A68F0: hud_pipe_query_install (hud_driver_query.c:175)
==17630== by 0x48A6A30: hud_driver_query_install (hud_driver_query.c:207)
==17630== by 0x48A5835: hud_create (hud_context.c:791)
==17630== by 0x48756CB: dri_create_context (dri_context.c:165)
==17630== by 0x4871CD4: driCreateContextAttribs (dri_util.c:435)
==17630== by 0x4871E06: driCreateNewContext (dri_util.c:464)
==17630== by 0x4056A22: dri2_create_context (dri2_glx.c:223)
==17630== by 0x402CF68: CreateContext (glxcmds.c:299)
==17630== by 0x402D265: glXCreateContext (glxcmds.c:430)
==17630== by 0x804B136: ??? (in /usr/bin/glxgears)
This is due to second vertex element being specified, and the upload
tries to fetch over the end. However the pane rendering only requires
a single vertex element, so specify only one.
Reviewed-by: Marek Olšák <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
texstore_swizzle path cannot handle it (and didn't detect this).
Unfortunately there's no piglit test trying to specify textures with a
GL_COLOR_INDEX source format, and I don't really understand how all the color
map stuff which is used by this works, but this caused conform failures
(with a reported mesa implementation error when trying to figure out the color
mapping).
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
accel_working2 returns 3 if the new firmware is used.
The comment wasn't updated in v3 of commit:
36771dc winsys/radeon: fix nop packet padding for hawaii
Signed-off-by: Andreas Boll <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes piglit glean "do-loop with continue and break" on RS690
It's based on Tom Stellard patch and improved to handle CMP instruction.
[v2] handle CMP instruction
Reviewed-by: Tom Stellard <[email protected]>
Signed-off-by: David Heidelberger <[email protected]>
|
|
|
|
|
|
|
|
| |
This is required by the spec.
Reviewed-by: Francisco Jerez <[email protected]>
CC: "10.2" <[email protected]>
|
|
|
|
|
|
|
|
| |
We were leaking the input buffer used for kernel arguments and since
we were allocating it using si_upload_const_buffer() we were leaking
1 MB per kernel invocation.
CC: "10.2" <[email protected]>
|
|
|
|
| |
CC: "10.2" <[email protected]>
|
|
|
|
|
|
|
| |
This will decrement the reference count for buffers referenced in the
command stream will prevent us from leaking them.
CC: "10.2" <[email protected]>
|
|
|
|
| |
CC: "10.2" <[email protected]>
|
|
|
|
| |
CC: "10.2" <[email protected]>
|
|
|
|
|
|
|
|
| |
There is a hard limit in older kernels of 256 MB for buffer allocations,
so report this value as MAX_MEM_ALLOC_SIZE and adjust MAX_GLOBAL_SIZE
to statisfy requirements of OpenCL.
CC: "10.2" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, when we encountered a situation where we had to optimistically
color a node, we would immediately give up and push all the remaining
nodes on the stack in the order of their index - which is a random, and
potentially not optimal, order. Instead, choose one node to
optimistically color in ra_select(), and then once we've optimistically
colored it, keep on going as normal in the hopes that we've opened up
more avenues for the normal select phase to make progress. In cases with
high register pressure, this helps make the order we push things on the
stack much better, and therefore increase the chance that we can allocate
successfully.
total instructions in shared programs: 4545447 -> 4545401 (-0.00%)
instructions in affected programs: 1353 -> 1307 (-3.40%)
GAINED: 124
LOST: 6
Signed-off-by: Connor Abbott <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we would consider any optimistically colored nodes for
spilling. However, spilling any optimistically colored nodes below the
node that we failed to color on the stack wouldn't help us make
progress, since it wouldn't help with allowing us to find a color for
the node currently failing to get colored. Only consider nodes
which were above the failing node on the stack for spilling, which
simplifies the logic, and comment the code better so people know what's
going on here.
No shader-db changes with BRW_MAX_GRF reduced to 90 (or with the normal
number of GRF's).
Signed-off-by: Connor Abbott <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can store the q total that pq_test() would've calculated in the node
itself, updating it when we add a node to the stack. This way, we only
have to walk the adjacency list when we push a node on the stack (i.e.
when the p, q test succeeds) instead of every time we do the p, q test.
No difference in shader-db run times, but I'm keeping this in because
the q total that it calculates will also be used in the next few commits.
Signed-off-by: Connor Abbott <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, there were 3 entrypoints into parts of the actual allocator,
and an API called ra_allocate_no_spills() that called all 3. Nobody
would ever want to call any of the 3 entrypoints by themselves, so
everybody just used ra_allocate_no_spills(). So just make them static
functions, and while we're at it rename ra_allocate_no_spills() to
ra_allocate() since there's no equivalent "with spills," because the
backend is supposed to handle spilling.
Signed-off-by: Connor Abbott <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
This would try to allocate 0-sized bo's when the max level was below the
base level.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
|