summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* i965/vec4: Assert that fine/coarse derivative ops don't appearChris Forbes2014-08-151-0/+4
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* glsl: Mark program as using dFdy if coarse/fine variant is usedChris Forbes2014-08-151-1/+3
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* nv50,nvc0: add support for fine derivativesIlia Mirkin2014-08-145-3/+8
| | | | | | | The quadop-based method we currently use on all chipsets already provides the fine version of the derivatives. Signed-off-by: Ilia Mirkin <[email protected]>
* mesa/st: add support for emitting fine derivative opcodesIlia Mirkin2014-08-142-2/+10
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium: add opcodes/cap for fine derivative supportIlia Mirkin2014-08-1419-5/+34
| | | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> (v1) Reviewed-by: Roland Scheidegger <[email protected]> (v1) v2: Reuse opcode gaps as suggested by Marek
* mesa/program: add new derivative unops to the unexpected listIlia Mirkin2014-08-141-0/+4
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* glsl: add ARB_derivative control supportIlia Mirkin2014-08-148-0/+74
| | | | | | | 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]>
* mesa: add ARB_derivative_control extension bitIlia Mirkin2014-08-142-0/+2
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* mesa: add ARB_texture_barrier supportIlia Mirkin2014-08-146-1/+21
| | | | | | | | | 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]>
* docs: document radeonsi BPTC support, sort extensions in 10.3 release notesMarek Olšák2014-08-152-6/+6
|
* r600g: Implement BPTC texture supportGlenn Kennard2014-08-153-2/+26
| | | | | | | Requires Evergreen/Cayman Signed-off-by: Glenn Kennard <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* i965: Rename intelValidateState to intel_update_stateKristian Høgsberg2014-08-142-9/+7
| | | | | | | | 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]>
* i965: Assign PS kernel start pointers when we decide which kernels to useKristian Høgsberg2014-08-143-23/+28
| | | | | | | | | | | 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]>
* radeonsi: implement BPTC texture supportGrigori Goronzy2014-08-141-0/+20
| | | | | | | | Passes all piglit tests. v2: rebased Signed-off-by: Marek Olšák <[email protected]>
* radeonsi: fix buffer invalidation of unbound texture buffer objectsMarek Olšák2014-08-143-7/+17
| | | | | | | This maintains a list of all TBOs in a pipe_context. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Michel Dänzer <[email protected]>
* r600g: implement invalidation of texture buffer objectsMarek Olšák2014-08-145-5/+51
| | | | | | This fixes piglit spec/ARB_texture_buffer_object/data-sync. Reviewed-by: Alex Deucher <[email protected]>
* r600g: fix constant buffer fetchesMarek Olšák2014-08-141-0/+1
| | | | | | | | | 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]>
* r600g: clear constant buffer sizes at the beginning of CSMarek Olšák2014-08-143-87/+49
| | | | Reviewed-by: Alex Deucher <[email protected]>
* egl_dri2: fix EXT_image_dma_buf_import fdsPekka Paalanen2014-08-141-31/+6
| | | | | | | | | | | | | | | | | | 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]>
* i965: fix compiler error in union initiliazerPekka Paalanen2014-08-142-2/+2
| | | | | | | | | | | | | | | | 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]>
* i965: Bail on FS copy propagation for scratch writes with source modifiersAnuj Phogat2014-08-141-0/+4
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Bail on vec4 copy propagation for scratch writes with source modifiersAnuj Phogat2014-08-141-0/+4
| | | | | | | | | 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]>
* glsl: Fixed vectorize pass vs. texture lookups.Aras Pranckevicius2014-08-141-0/+13
| | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82574 Reviewed-by: Matt Turner <[email protected]>
* ra: move declarations before code to fix MSVC buildBrian Paul2014-08-141-2/+2
| | | | Trivial.
* svga: remove some unneeded INLINE qualifiersBrian Paul2014-08-143-5/+5
| | | | Trivial.
* docs/autoconf: update to better reflect realityEmil Velikov2014-08-141-16/+36
| | | | | | | | | | | | | * --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)
* scons: do not include headers from the sources listsJose Fonseca2014-08-141-0/+3
| | | | | | | | | | 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]>
* configure.ac: remove enable 32/64 bit hacksEmil Velikov2014-08-142-38/+4
| | | | | | | | | | | | | | | | 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]>
* Revert "configure: Fix --enable-XX-bit flags by moving LT_INIT where it should"Emil Velikov2014-08-141-8/+3
| | | | | | | | | | | | | | | | | | | | | 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]>
* i965: Store uniform constant values in a gl_constant_value instead of floatNeil Roberts2014-08-1413-42/+55
| | | | | | | | | | | | | | | | | | | | | | 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]>
* st/vdpau: add device reference countingChristian König2014-08-148-11/+46
| | | | | | | | | | 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]>
* mesa: Make ARB_gpu_shader5 core-profile-onlyChris Forbes2014-08-141-1/+1
| | | | | | | | | 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]>
* nouveau: force luminance clear colors to have the same g/b values as rIlia Mirkin2014-08-142-4/+21
| | | | | | | Fixes the LUMINANCE_ALPHA formats of fbo-clear-formats piglit test. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* i965: Enable INTDIV in SIMD16 mode.Kenneth Graunke2014-08-132-14/+2
| | | | | | | | | | 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]>
* i965/fs: Drop "do dual source blending" generator parameter.Kenneth Graunke2014-08-134-7/+3
| | | | | | | | | | 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]>
* mesa/texstore: Don't use the _mesa_swizzle_and_convert if we need transfer opsJason Ekstrand2014-08-131-0/+3
| | | | | | | | 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]>
* docs: update ARB_vertex_attrib_64bit statusDave Airlie2014-08-141-1/+1
| | | | | | I started this as well on top of my fp64 stuff. Signed-off-by: Dave Airlie <[email protected]>
* docs/GL3.txt: add GLES 3.1 sectionDave Airlie2014-08-141-1/+17
| | | | | | | | | | 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]>
* hud: don't overrun malloced arraysDave Airlie2014-08-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ==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]>
* mesa: fix texstore with GL_COLOR_INDEX dataRoland Scheidegger2014-08-141-0/+3
| | | | | | | | | | | | | 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]>
* winsys/radeon: fix hawaii accel_working2 commentAndreas Boll2014-08-131-1/+1
| | | | | | | | | | 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]>
* r300g: Fix bug in build_loop_info()/compiler v2Tom Stellard2014-08-131-11/+23
| | | | | | | | | | | 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]>
* clover: Flush the command queue in clReleaseCommandQueue()Tom Stellard2014-08-131-1/+5
| | | | | | | | This is required by the spec. Reviewed-by: Francisco Jerez <[email protected]> CC: "10.2" <[email protected]>
* radeonsi/compute: Stop leaking the input bufferTom Stellard2014-08-131-7/+14
| | | | | | | | 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]>
* radeonsi/compute: Whitespace fixesTom Stellard2014-08-131-2/+1
| | | | CC: "10.2" <[email protected]>
* radeonsi/compute: Call si_pm4_free_state() after emitting compute stateTom Stellard2014-08-131-1/+1
| | | | | | | This will decrement the reference count for buffers referenced in the command stream will prevent us from leaking them. CC: "10.2" <[email protected]>
* radeonsi/compute: Update reference counts for buffers in si_set_global_binding()Tom Stellard2014-08-131-2/+2
| | | | CC: "10.2" <[email protected]>
* radeon/compute: Report a value for PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZETom Stellard2014-08-132-1/+17
| | | | CC: "10.2" <[email protected]>
* radeon/compute: Fix reported values for MAX_GLOBAL_SIZE and MAX_MEM_ALLOC_SIZETom Stellard2014-08-131-13/+19
| | | | | | | | 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]>
* ra: optimistically color only one node at a timeConnor Abbott2014-08-131-35/+22
| | | | | | | | | | | | | | | | | | | | | 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 07:05:57 +0000