summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* glsl: flag shaders which use gather4 at allChris Forbes2013-10-032-0/+11
| | | | | Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/vs: Add support for ir_tg4Chris Forbes2013-10-032-2/+45
| | | | | | | | | | Pretty much the same as the FS case. Channel select goes in the header, V2: Less mangling. V3: Avoid sampling at all, for degenerate swizzles. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/fs: Add support for ir_tg4Chris Forbes2013-10-032-3/+60
| | | | | | | | | | | | | | | | | | | | Lowers ir_tg4 (from textureGather and textureGatherOffset builtins) to SHADER_OPCODE_TG4. The usual post-sampling swizzle workaround can't work for ir_tg4, so avoid doing that: * For R/G/B/A swizzles use the hardware channel select (lives in the same dword in the header as the texel offset), and then don't do anything afterward in the shader. * For 0/1 swizzles blast the appropriate constant over all the output channels instead of sampling. V2: Avoid duplicating header enabling block V3: Avoid sampling at all, for degenerate swizzles. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: add SHADER_OPCODE_TG4Chris Forbes2013-10-036-2/+17
| | | | | | | | | | Adds the Gen7 message IDs, a new SHADER_OPCODE_TG4 pseudo-op, and low-level support for emitting it via generate_tex(). V3: Updated for changes in master. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* glsl: add texture gather changesMaxence Le Dore2013-10-0314-4/+60
| | | | | | | | | | V2 [Chris Forbes]: - Add new pattern, fixup parameter reading. V3: Rebase onto new builtins machinery Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* mesa: add texture gather changesMaxence Le Dore2013-10-038-1/+36
| | | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* i965: fix bogus swizzle in brw_cubemap_normalizeChris Forbes2013-10-031-4/+6
| | | | | | | | | | | | | | | | When used with a cube array in VS, failed assertion in ir_validate: Assignment count of LHS write mask channels enabled not matching RHS vector size (3 LHS, 4 RHS). To fix this, swizzle the RHS correctly for the writemask. This showed up in the ARB_texture_gather tests, which exercise cube arrays in the VS. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Cc: "9.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* r600/llvm: Adds support for MSAAVincent Lejeune2013-10-023-1/+54
|
* r600g/llvm: Undef z and w component of 2D TXP instVincent Lejeune2013-10-021-1/+2
|
* r600g/llvm: fix txq for texture bufferVincent Lejeune2013-10-023-2/+9
|
* i965: compute DDX in a subspan based only on top rowChia-I Wu2013-10-027-8/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | Consider only the top-left and top-right pixels to approximate DDX in a 2x2 subspan, unless the application requests a more accurate approximation via GL_FRAGMENT_SHADER_DERIVATIVE_HINT or this optimization is disabled from the new driconf option disable_derivative_optimization. This results in a less accurate approximation. However, it improves the performance of Xonotic with Ultra settings by 24.3879% +/- 0.832202% (at 95.0% confidence) on Haswell. No noticeable image quality difference observed. The improvement comes from faster sample_d. It seems, on Haswell, some optimizations are introduced to allow faster sample_d when all pixels in a subspan have the same derivative. I considered SAMPLE_STATE too, which allows one to control the quality of sample_d on Haswell. But it gave much worse image quality without giving better performance comparing to this change. No piglit quick.tests regression on Haswell (tested with v1). v2: better guess for precompile program key Signed-off-by: Chia-I Wu <olv@lunarg.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
* i965/blorp: Use passed in framebuffer rather than ctx->DrawBufferChris Forbes2013-10-021-4/+4
| | | | | | | | We have the destination framebuffer object passed in; there's no need to go digging around in the context. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
* ralloc: Remove the rzalloc-based new/delete operator definition macro.Francisco Jerez2013-10-011-14/+12
| | | | | | | | | | Using it encourages the (IMHO worrying) practice of leaving member variables uninitialized in constructor definitions. This macro shouldn't be necessary anymore after the last patch series fixing all its users to initialize all member variables from the class constructor. Remove it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* st/mesa: Switch glsl_to_tgsi_instruction to the non-zeroing allocator.Francisco Jerez2013-10-011-1/+1
| | | | | | | | All member variables of glsl_to_tgsi_instruction are already being initialized from its implicitly defined constructor, it's not necessary to use rzalloc to allocate its memory. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* mesa/program: Switch ir_to_mesa_instruction to the non-zeroing allocator.Francisco Jerez2013-10-011-1/+1
| | | | | | | | All member variables of ir_to_mesa_instruction are already being initialized from its implicitly defined constructor, it's not necessary to use rzalloc to allocate its memory. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Switch vec4_live_variables to the non-zeroing allocator.Francisco Jerez2013-10-011-1/+1
| | | | | | | | | | | | | | | | All member variables of vec4_live_variables are already being initialized from its constructor, it's not necessary to use rzalloc to allocate its memory, and doing so makes it more likely that we will start relying on the allocator to zero out all memory if the class is ever extended with new member variables. That's bad because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Switch fs_live_variables to the non-zeroing allocator.Francisco Jerez2013-10-011-1/+1
| | | | | | | | | | | | | | | | All member variables of fs_live_variables are already being initialized from its constructor, it's not necessary to use rzalloc to allocate its memory, and doing so makes it more likely that we will start relying on the allocator to zero out all memory if the class is ever extended with new member variables. That's bad because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Switch fs_inst to the non-zeroing allocator.Francisco Jerez2013-10-011-1/+1
| | | | | | | | | | | | | | | | All member variables of fs_inst are already being initialized from its constructor, it's not necessary to use rzalloc to allocate its memory, and doing so makes it more likely that we will start relying on the allocator to zero out all memory if the class is ever extended with new member variables. That's bad because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Switch ip_record to the non-zeroing allocator.Francisco Jerez2013-10-011-1/+1
| | | | | | | | | | | | | | | | All member variables of ip_record are already being initialized from its constructor, it's not necessary to use rzalloc to allocate its memory, and doing so makes it more likely that we will start relying on the allocator to zero out all memory if the class is ever extended with new member variables. That's bad because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Initialize all member variables of cfg_t on construction.Francisco Jerez2013-10-012-1/+2
| | | | | | | | | | | | | The cfg_t object relies on the memory allocator zeroing out its contents before it's initialized, which is quite an unusual practice in the C++ world because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. Initialize all fields from the constructor and stop using the zeroing allocator. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Initialize all member variables of bblock_t on construction.Francisco Jerez2013-10-012-2/+3
| | | | | | | | | | | | | | | The bblock_t object relies on the memory allocator zeroing out its contents before it's initialized, which is quite an unusual practice in the C++ world because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. Initialize all fields from the constructor and stop using the zeroing allocator. v2: Use zero initialization for numeric types instead of default construction. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* glsl: Switch ast_type_qualifier to the non-zeroing allocator.Francisco Jerez2013-10-011-1/+1
| | | | | | | | All member variables of ast_type_qualifier are already being initialized from its implicitly defined constructor, it's not necessary to use rzalloc to allocate its memory. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* glsl: Switch ast_node to the non-zeroing allocator.Francisco Jerez2013-10-012-2/+11
| | | | | | | | | | | | | | | | | | All member variables of ast_node are already being initialized from its constructor, but some of its derived classes were leaving members uninitialized -- Fix them. Using rzalloc makes it more likely that we will start relying on the allocator to zero out all memory if the class is ever extended with new member variables. That's bad because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. v2: Use NULL initialization instead of default construction for pointers. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Initialize all member variables of vec4_instruction on construction.Francisco Jerez2013-10-012-1/+16
| | | | | | | | | | | | | | | The vec4_instruction object relies on the memory allocator zeroing out its contents before it's initialized, which is quite an unusual practice in the C++ world because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. Initialize all fields from the constructor and stop using the zeroing allocator. Reviewed-by: Paul Berry <stereotype441@gmail.com> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.Francisco Jerez2013-10-012-3/+15
| | | | | | | | | | | | | | | The _mesa_glsl_parse_state object relies on the memory allocator zeroing out its contents before it's initialized, which is quite an unusual practice in the C++ world because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. Initialize all fields from the constructor and stop using the zeroing allocator. Reviewed-by: Paul Berry <stereotype441@gmail.com> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* mesa: Fix misplaced includes of "main/uniforms.h".Francisco Jerez2013-10-015-5/+4
| | | | | | | | | | | Several C++ source files include "main/uniforms.h" from an extern "C" block, which is both unnecessary, because "uniforms.h" already checks for a C++ compiler and sets the right linkage, and incorrect, because the header file includes other C++ headers ("glsl_types.h" and "ir_uniform.h") that are supposed to get C++ linkage. Reviewed-by: Paul Berry <stereotype441@gmail.com> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
* st/egl: flush resources before presentationGrigori Goronzy2013-10-011-0/+11
| | | | | | | Fixes regression on r600g due to fast clear introduced by commit edbbfac6. Signed-off-by: Marek Olšák <marek.olsak@amd.com>
* i965/gs: Fix incorrect numbering of DWORDs in 3DSTATE_GSPaul Berry2013-10-011-3/+4
| | | | | | | | | | | | | | | In commit 247f90c77e8f3894e963d796628246ba0bde27b5 (i965/gs: Set control data header size/format appropriately for EndPrimitive()), I incorrectly numbered the DWORDs in the 3DSTATE_GS command starting from 1 instead of starting from 0. This caused the control data format to be programmed into the wrong DWORD, resulting in corruption in some geometry shaders that used an output type of points. This patch numbers the DWORDs starting from 0, as we do for all other commands, which causes the control data format to be programmed into the correct DWORD. Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
* mesa: check for bufSize > 0 in _mesa_GetSynciv()Brian Paul2013-10-011-1/+1
| | | | | | | | The spec doesn't say GL_INVALID_VALUE should be raised for bufSize <= 0. In any case, memcpy(len < 0) will lead to a crash, so don't allow it. CC: "9.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* mesa: minor fix-ups for _mesa_validate_sync()Brian Paul2013-10-012-4/+13
| | | | | | Return bool instead of int. Const-qualify the syncObj. Add some comments. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* mesa: add missing error checks in _mesa_GetObject[Ptr]Label()Brian Paul2013-10-011-0/+12
| | | | | | | | | | | Error checking bufSize isn't mentioned in the spec, but it is in the man pages. However, I believe the man page is incorrect. Typically, GL functions that take GLsizei parameters check that they're positive or non-negative. Negative values don't make sense here. A spec bug has been filed with Khronos/ARB. v2: check for negative values, not <= 0.
* mesa: use caller string in error message in get_label_pointer()Brian Paul2013-10-011-1/+1
| | | | Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au>
* mesa: asst. clean-ups in copy_label()Brian Paul2013-10-011-10/+27
| | | | | | | | | | | This incorporates Vinson's change to check for a null src pointer as detected by coverity. Also, rename the function params to be src/dst, const-qualify src, and use GL types to match the calling functions. And add some more comments. Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au>
* st/xorg: Include u_surface.h for u_copy_rectAlex Deucher2013-10-011-0/+1
| | | | | | | Fixes build errors. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Brian Paul <brianp@vmware.com>
* winsys/freedreno/drm: drop obsolete .gitignoreEmil Velikov2013-10-011-1/+0
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* winsys/freedreno/drm: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-1/+4
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* winsys/nouveau/drm: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-3/+6
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* winsys/i915/sw: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-11/+8
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* st/xvmc: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-6/+8
| | | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* st/xorg: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-25/+15
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* st/xa: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-7/+9
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* st/wgl: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-18/+16
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* st/vega: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-63/+33
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* st/vdpau: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-12/+14
| | | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* st/osmesa: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-2/+4
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* st/glx: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-015-17/+11
| | | | | | | Move glx/{,xlib/}Makefile.am to preserve file list Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* st/gbm: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-1/+4
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* st/egl: consolidate C sources lists into Makefile.sourcesEmil Velikov2013-10-014-53/+53
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* st/dri/sw: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-13/+8
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
* st/dri: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-13/+8
| | | | | Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
generated by cgit v1.1 at 2025-02-04 05:50:38 +0000