summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* 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 <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* 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 <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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" <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* st/xorg: Include u_surface.h for u_copy_rectAlex Deucher2013-10-011-0/+1
| | | | | | | Fixes build errors. Signed-off-by: Alex Deucher <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* winsys/freedreno/drm: drop obsolete .gitignoreEmil Velikov2013-10-011-1/+0
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* winsys/freedreno/drm: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-1/+4
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* winsys/nouveau/drm: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-3/+6
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* winsys/i915/sw: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-11/+8
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* st/xvmc: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-6/+8
| | | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]> Reviewed-by: Christian König <[email protected]>
* st/xorg: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-25/+15
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* st/xa: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-7/+9
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* st/wgl: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-18/+16
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* st/vega: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-63/+33
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* st/vdpau: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-12/+14
| | | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]> Reviewed-by: Christian König <[email protected]>
* st/osmesa: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-2/+4
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* 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 <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* st/gbm: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-012-1/+4
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* st/egl: consolidate C sources lists into Makefile.sourcesEmil Velikov2013-10-014-53/+53
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* st/dri/sw: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-13/+8
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* st/dri: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-13/+8
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* st/clover: consolidate CPP sources list into Makefile.sourcesEmil Velikov2013-10-012-40/+43
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* galahad: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-014-25/+23
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* noop: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-014-17/+23
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* identity: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-014-15/+18
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* freedreno: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-016-41/+47
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* trace: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-13/+10
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* llvmpipe: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-85/+46
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* rbug: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-013-11/+9
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* softpipe: consolidate C sources list into Makefile.sourcesEmil Velikov2013-10-014-92/+37
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* r600: use NEED_RADEON_LLVM over R600_NEED_RADEON_GALLIUMEmil Velikov2013-10-011-1/+1
| | | | | | | | | libllvmradeon.la is available whenever NEED_RADEON_LLVM is set, using R600_NEED_RADEON_GALLIUM is rather ambiguous and unnecessary. Drop it in favour of NEED_RADEON_LLVM. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* gallium/radeon: drop unused variable LIBGALLIUM_LIBSEmil Velikov2013-10-011-3/+0
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* mesa/drivers: drop HAVE_*_DRI from individual makefilesEmil Velikov2013-10-016-19/+0
| | | | | | | | | The mesa/drivers/dri/Makefile.am already guards the individual targets/subdirs with HAVE_*_DRI before including them. Thus making the additional check within each Makefile.am unnecessary. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* gallium/targets: Make use of prebuilt libdricommon.la.Johannes Obermayr2013-10-018-38/+17
| | | | | | | | | | | | | | | libdricommon.la is available whenever a non swrast driver is built. All the classic dri drivers make use of the prebuild library but all of the gallium ones rebuild it explicitly. While we're here gallium/{llvm,soft}pipe does not require HAVE_COMMON_DRI thus do not set in during configure. v2: [Emil] Add commit message and drop HAVE_COMMON_DRI from configure.ac v3: [Emil] Rebase and resolve targets/r*/dri conflicts Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* i915: Fix memory leak in do_blit_readpixels.Vinson Lee2013-09-301-0/+1
| | | | | | | Fixes "Resource leak" defect reported by Coverity. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* llvmpipe: Remove unnecessary null check of shader.Vinson Lee2013-09-301-1/+1
| | | | | | | | | shader has already been dereferenced earlier so cannot be null here. Fixes "Dereference before null check" defect reported by Coverity. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Brian Paul <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 05:18:23 +0000