summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* pipe-loader: Fix llvmpipe.la pathMichel Dänzer2013-12-041-1/+1
| | | | | | Fixes make[3]: *** No rule to make target `.../src/gallium/drivers/softpipe/libllvmpipe.la', needed by `pipe_swrast.la'. Stop.
* i965: Fix BRW_BATCH_STRUCT to specify RENDER_RING, not UNKNOWN_RING.Kenneth Graunke2013-12-031-2/+2
| | | | | | | | | | | | | | | | I missed this in the boolean -> enum conversion. C cheerfully casts false -> 0 -> UNKNOWN_RING. On Gen4-5, this causes the render ring prelude hook to get called in the middle of the batch, which is crazy. BRW_BATCH_STRUCT is not used on Gen6+. Fixes regressions since 395a32717df494353703f3581edcd3ba380f16d6 ("i965: Introduce an UNKNOWN_RING state."). Fixes "fips -v glxgears" on Ironlake. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* Revert "i965: Move brw_emit_query_begin() to the render ring prelude."Kenneth Graunke2013-12-032-7/+3
| | | | | | | | | | | | This reverts commit a4bf7f6b6e612626c4e4fc21507ac213a7ba4b00. It breaks occlusion queries on Gen4-5. Doing this right will likely require larger changes, which should be done at a future date. Some Piglit tests still passed due to other bugs; fixing those revealed this problem. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix OACONTROL assertion failures on Ironlake.Kenneth Graunke2013-12-031-4/+8
| | | | | | | | | | | | | | | I guarded half of the callers to start/stop_oa_counters with generation checks, but missed the other half (which were added later). OACONTROL doesn't exist on Ironlake, so we better not write it. Also, there's no need---Ironlake's performance counters are always running. This patch moves the generation checks into start/stop_oa_counters, rather than requiring the caller to do them. Fixes assertion failures in Piglit's AMD_performance_monitor/measure. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* gallium/radeon: use PRIu64 macro for printing uint64_tEmil Velikov2013-12-032-4/+6
| | | | | Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Emil Velikov <[email protected]>
* pipe-loader: build llvmpipe on top of softpipeEmil Velikov2013-12-031-10/+7
| | | | | | | | One can select if they want to fallback to softpipe. Current approach makes this not possible, whereas other targets (dri-swrast) handle this approapriately. Signed-off-by: Emil Velikov <[email protected]>
* mesa: resolve typo DTXn/DXTnEmil Velikov2013-12-031-1/+1
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Emil Velikov <[email protected]>
* automake: include only one copy VERSION in tarballEmil Velikov2013-12-031-1/+0
| | | | | | | | | | | | | The VERSION file is tracked by git (git ls-files), thus adding it to EXTRA_FILES will result in a duplicate copy within the final tarball. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72230 Cc: "10.0" <[email protected]> Reported-by: Patrick Steinhardt <[email protected]> Tested-by: Patrick Steinhardt <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Emil Velikov <[email protected]>
* glx: Add missing null check in gxl/dri2_glx.cJuha-Pekka Heikkila2013-12-031-0/+4
| | | | | | Signed-off-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* glx: Check malloc return value before accessing memory in glx/clientattrib.cJuha-Pekka Heikkila2013-12-031-0/+4
| | | | | | Signed-off-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965: Add extra-alignment for non-msrt fast color clear for all hw (v2)Chad Versace2013-12-031-24/+11
| | | | | | | | | | | | | | | | | | | | | | The BSpec states that the aligment for the non-msrt clear rectangle must be doubled; the BSpec does not restricit the workaround to specific hardware. Commit 9a1a67b applied the workaround to Haswell GT3. Commit 8b659ce expanded the workaround to all Haswell variants. This commit expands it to all hardware. No Piglit regressions on Ivybridge 0x0166. No fixes either. I know no Ivybridge nor Baytrail bug related to this workaround. However, the BSpec says the extra alignment is required, so let's do it. v2: Apply to all hardware, not just gen7. CC: "9.2, 10.0" <[email protected]> CC: Anuj Phogat <[email protected]> Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* configure.ac: require libdrm_radeon 2.4.50Marek Olšák2013-12-031-1/+1
|
* st/mesa: implement layered framebuffer clear for the clear_with_quad fallbackMarek Olšák2013-12-034-16/+68
| | | | Same approach as in u_blitter.
* gallium/util: implement layered framebuffer clear in u_blitterMarek Olšák2013-12-0310-30/+110
| | | | | | | | | | | | | All bound layers (from first_layer to last_layer) should be cleared. This uses a vertex shader which outputs gl_Layer = gl_InstanceID, so each instance goes to a different layer. By rendering a quad and setting the instance count to the number of layers, it will trivially clear all layers. This requires AMD_vertex_shader_layer (or PIPE_CAP_TGSI_VS_LAYER), which only radeonsi supports at the moment. r600 could do this too. Standard DX11 hardware will have to use a geometry shader though, which has higher overhead.
* gallium: add support for AMD_vertex_shader_layerMarek Olšák2013-12-0316-1/+32
|
* radeonsi: add driver support for layered rendering and AMD_vertex_shader_layerMarek Olšák2013-12-034-12/+27
| | | | Reviewed-by: Michel Dänzer <[email protected]>
* radeonsi: implement OpenGL edge flagsMarek Olšák2013-12-033-6/+48
| | | | Reviewed-by: Michel Dänzer <[email protected]>
* st/mesa: add support for layered framebuffers and consolidate codeMarek Olšák2013-12-036-93/+99
| | | | | | | | | This is a subset of geometry shaders. It's all about setting first_layer and last_layer correctly. Also some code between st_render_texture and update_framebuffer_state is consolidated. It doesn't use rtt_level and derives the level from dimensions instead as the code in st_atom_framebuffer.c did.
* mesa: expose AMD_vertex_shader_layer in the core profile onlyMarek Olšák2013-12-031-1/+1
| | | | | | | It needs glFramebufferTexture, which isn't available in the compatibility profile. Reviewed-by: Ian Romanick <[email protected]>
* egl: add HAVE_LIBDRM define, fix EGL X11 platformTapani Pälli2013-12-032-6/+8
| | | | | | | | | | | | | | | | | | | | Commit a594cec broke EGL X11 backend by adding dependency between X11 and DRM backends requiring HAVE_EGL_PLATFORM_DRM defined for X11. This patch fixes the issue by adding additional define for libdrm detection independent of which backend is being compiled. Tested by compiling Mesa with '--with-egl-platforms=x11' and running es2gears_x11 + glbenchmark2.7 successfully. v2: return true for dri2_auth if running without libdrm (Samuel) v3: check libdrm when building EGL drm platform + AM_CFLAGS fix (Emil) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72062 Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Chad Versace <[email protected]> Cc: Samuel Thibault <[email protected]> Cc: [email protected]
* freedreno: Add a few texture formatsAndreas Heider2013-12-021-0/+3
|
* i965: Skip the register write check on Broadwell.Kenneth Graunke2013-12-021-1/+5
| | | | | | | | | MI_STORE_REGISTER_MEM has to take a 48-bit address, so the existing code doesn't work. But supposedly Broadwell has a register whitelist and just works out of the box anyway, so there's no need to check. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix texture border color on Broadwell.Kenneth Graunke2013-12-021-1/+11
| | | | | | | | | | | | The Gen7 sampler state code still works. Increasing the alignment to 64 bytes makes bit 5 zero, which is good because it's now reserved. Since we don't use the new filter bits, we can leave those as zero too, which means we don't need to update the code to update the pointer. (We probably should anyway, for clarity, but alas, another day.) Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Don't use MACH for integer multiplies on Gen8+.Kenneth Graunke2013-12-022-2/+2
| | | | | | | | | | | The documentation is really hard to follow, but apparently a 32-bit x 32-bit multiply just works without the MACH macro. The macro apparently is only necessary to get the full 64-bit value. Fixes Piglit tests [vf]s-op-mult-int-int.shader_test. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix texture swizzling on Broadwell.Kenneth Graunke2013-12-021-1/+1
| | | | | | | | Like Haswell, we do this in SURFACE_STATE rather than shader workarounds. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Set vertical alignment unit to 4 on Broadwell.Kenneth Graunke2013-12-021-0/+6
| | | | | | | | | | | | Broadwell doesn't support a surface vertical alignment of 2. It only supports VALIGN_4, VALIGN_8, or VALIGN_16. I chose 4 since it's the least wasteful. v2: Replace my comment with a better one from Eric. Move Broadwell checks earlier so it's more obvious that "return 2" won't be hit. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/vs: Always store pull constant offsets in GRFs on Gen8.Kenneth Graunke2013-12-021-1/+15
| | | | | | | | | | | | We need to SEND from a GRF, and we can only obtain those prior to register allocation. This allows us to do pull constant loads without the MRF hack. v2: Reword comments (suggested by Paul). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/vs: Don't copy propagate into SEND-from-GRF messages.Kenneth Graunke2013-12-021-0/+3
| | | | | | | | SEND can't deal with swizzles, source modifiers, and so on. This should avoid problems with VS pull constant loads on Broadwell. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* clover: Fix missing minus sign in 'iterator_adaptor::operator-='.Francisco Jerez2013-12-021-1/+1
| | | | | The method is currently unused, this probably doesn't fix anything at this point.
* i965/hsw: Apply non-msrt fast color clear w/a to all HSW GTsChad Versace2013-12-021-6/+12
| | | | | | | | | | | | | | | | | | | | | | Pre-patch, the workaround was applied to only HSW GT3. However, the workaround also fixes render corruption on the HSW GT1 Chromebook, codenamed Falco. Also, update the BSpec quote that discusses the workaround to reflect the latest BSpec. The BSpec states that the workaround is required for Ivybridge and Baytrail as well as Haswell. But, we apply the workaround to only Haswell because (a) we suspect that is the only hardware where it is actually required and (b) we haven't yet validated the workaround for the other hardware. CC: "9.2, 10.0" <[email protected]> CC: Anuj Phogat <[email protected]> OTC-Tracker: CHRMOS-812 Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* glsl: Simplify the built-in function linking code.Kenneth Graunke2013-12-017-36/+31
| | | | | | | | | | | | | | | | | | Previously, we stored an array of up to 16 additional shaders to link, as well as a count of how many each shader actually needed. Since the built-in functions rewrite, all the built-ins are stored in a single shader. So all we need is a boolean indicating whether a shader needs to link against built-ins or not. During linking, we can avoid creating the temporary array if none of the shaders being linked need built-ins. Otherwise, it's simply a copy of the array that has one additional element. This is much simpler. This patch saves approximately 128 bytes of memory per gl_shader object. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Create an accessor for the built-in function shader.Kenneth Graunke2013-12-012-2/+13
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Drop crazy looping from no_matching_function_error().Kenneth Graunke2013-12-011-16/+23
| | | | | | | | | | | | Since the built-in functions rewrite, num_builtins_to_link is always either 0 or 1, so we don't need tho crazy loop starting at -1 with a special case. All we need to do is print the prototypes from the current shader, and the single built-in function shader (if present). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Merge "candidates are: " message to the previous line.Kenneth Graunke2013-12-011-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, when we hit a "no matching function" error, it looked like: 0:0(0): error: no matching function for call to `cos()' 0:0(0): error: candidates are: float cos(float) 0:0(0): error: vec2 cos(vec2) 0:0(0): error: vec3 cos(vec3) 0:0(0): error: vec4 cos(vec4) Now it looks like: 0:0(0): error: no matching function for call to `cos()'; candidates are: 0:0(0): error: float cos(float) 0:0(0): error: vec2 cos(vec2) 0:0(0): error: vec3 cos(vec3) 0:0(0): error: vec4 cos(vec4) This is not really any worse and removes the need for the prefix variable. It will also help with the next commit's refactoring. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Drop unused call_ir parameter from generate_call().Kenneth Graunke2013-12-011-8/+6
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Remove useless iteration through function parameters.Kenneth Graunke2013-12-011-6/+0
| | | | | | | | | There's no need to loop through the "parameters" list and remove every element; move_nodes_to(&parameters) already throws away all elements of the destination list. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* Fix 'make check' in src/mapi/glapi/tests when builddir != srcdirJon TURNEY2013-12-011-0/+1
| | | | | | | | | | make[5]: Entering directory `/jhbuild/build/mesa/mesa/src/mapi/glapi/tests' CXX check_table.o /jhbuild/checkout/mesa/mesa/src/mapi/glapi/tests/check_table.cpp:29:30: fatal error: glapi/glapitable.h: No such file or directory We should look for the generated file glapi/glapitable.h in builddir, not srcdir Signed-off-by: Jon TURNEY <[email protected]>
* docs: Import 10.0 release notes, add news itemIan Romanick2013-11-302-3/+80
| | | | Signed-off-by: Ian Romanick <[email protected]>
* i965/gen6: Fix multisample resolve blits for luminance/intensity 32F formats.Paul Berry2013-11-291-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | On gen6, multisamble resolve blits use the SAMPLE message to blend together the 4 samples for each texel. For some reason, SAMPLE doesn't blend together the proper samples when the source format is L32_FLOAT or I32_FLOAT, resulting in blocky artifacts. To work around this problem, sample from the source surface using R32_FLOAT. This shouldn't affect rendering correctness, because when doing these resolve blits, the destination format is R32_FLOAT, so the channel replication done by L32_FLOAT and I32_FLOAT is unnecessary. Fixes piglit tests on Sandy Bridge: - spec/ARB_texture_float/multisample-formats 2 GL_ARB_texture_float - spec/ARB_texture_float/multisample-formats 4 GL_ARB_texture_float No piglit regressions on Sandy Bridge. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70601 Cc: Kenneth Graunke <[email protected]> Cc: [email protected] Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Remove unused field loop_variable_state::loop.Paul Berry2013-11-291-5/+0
| | | | | | This field was neither initialized nor used. It was just dead memory. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Improve documentation of ir_loop counter/control fields.Paul Berry2013-11-291-6/+28
| | | | | Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: In ir_validate, check that ir_loop::counter always refers to a new var.Paul Berry2013-11-291-0/+13
| | | | | | | | | | | | | The compiler back-ends (i965's fs_visitor and brw_visitor, ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this for some time. Thanks to the preceding patch, the compiler front-end no longer breaks this assumption. This patch adds code to validate the assumption so that if we have future bugs, we'll be able to catch them earlier. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Fix inconsistent assumptions about ir_loop::counter.Paul Berry2013-11-293-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The compiler back-ends (i965's fs_visitor and brw_visitor, ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when ir_loop::counter is non-null, it points to a fresh ir_variable that should be used as the loop counter (as opposed to an ir_variable that exists elsewhere in the instruction stream). However, previous to this patch: (1) loop_control_visitor did not create a new variable for ir_loop::counter; instead it re-used the existing ir_variable. This caused the loop counter to be double-incremented (once explicitly by the body of the loop, and once implicitly by ir_loop::increment). (2) ir_clone did not clone ir_loop::counter properly, resulting in the cloned ir_loop pointing to the source ir_loop's counter. (3) ir_hierarchical_visitor did not visit ir_loop::counter, resulting in the ir_variable being missed by reparenting. Additionally, most optimization passes (e.g. loop unrolling) assume that the variable mentioned by ir_loop::counter is not accessed in the body of the loop (an assumption which (1) violates). The combination of these factors caused a perfect storm in which the code worked properly nearly all of the time: for loops that got unrolled, (1) would introduce a double-increment, but loop unrolling would fail to notice it (since it assumes that ir_loop::counter is not accessed in the body of the loop), so it would unroll the loop the correct number of times. For loops that didn't get unrolled, (1) would introduce a double-increment, but then later when the IR was cloned for linking, (2) would prevent the loop counter from being cloned properly, so it would look to further analysis stages like an independent variable (and hence the double-increment would stop occurring). At the end of linking, (3) would prevent the loop counter from being reparented, so it would still belong to the shader object rather than the linked program object. Provided that the client program didn't delete the shader object, the memory would never get reclaimed, and so the shader would function properly. However, for loops that didn't get unrolled, if the client program did delete the shader object, and the memory belonging to the loop counter got re-used, this could cause a use-after-free bug, leading to a crash. This patch fixes loop_control_visitor, ir_clone, and ir_hierarchical_visitor to treat ir_loop::counter the same way the back-ends treat it: as a freshly allocated ir_variable that needs to be visited and cloned independently of other ir_variables. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72026 Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Teach ir_variable_refcount about ir_loop::counter variables.Paul Berry2013-11-292-0/+22
| | | | | | | | | | | | | | | | | If an ir_loop has a non-null "counter" field, the variable referred to by this field is implicitly read and written by the loop. We need to account for this in ir_variable_refcount, otherwise there is a danger we will try to dead-code-eliminate the loop counter variable. Note: at the moment the dead code elimination bug doesn't occur due to a bug in ir_hierarchical_visitor: it doesn't visit the "counter" field, so dead code elimination doesn't treat it as a candidate for elimination. But the patch to follow will fix that bug, so we need to fix ir_variable_refcount first in order to avoid breaking dead code elimination. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: fix mem leak of glPixelMap data in display listBrian Paul2013-11-291-13/+16
| | | | | | And simplify save_PixelMapfv() by using the memdup() function. Reviewed-by: Ian Romanick <[email protected]>
* mesa: added memory-related comment in save_error()Brian Paul2013-11-291-0/+4
| | | | Reviewed-by: Ian Romanick <[email protected]>
* mesa: fix flags assignment in save_WaitSync()Brian Paul2013-11-291-1/+1
| | | | | | | | The flags value is a bitfield so use the union's 'bf' field, not 'e' (enum) field. There's no actual change in behavior here since both fields of the union are the same size. Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove old colortable, histogram, etc. code from dlist.cBrian Paul2013-11-291-551/+0
| | | | | | | Trying to compile any of these functions into a display list now just generates a GL_INVALID_OPERATION error. Reviewed-by: Ian Romanick <[email protected]>
* mesa: have old convolution functions generate GL_INVALID_OPERATIONBrian Paul2013-11-291-12/+12
| | | | Reviewed-by: Ian Romanick <[email protected]>
* mesa: have old glColorTable functions generate GL_INVALID_OPERATIONBrian Paul2013-11-291-10/+10
| | | | | | As is done for the old histogram functions. Reviewed-by: Ian Romanick <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 20:33:55 +0000