summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* Remove Xcalloc/Xmalloc/Xfree callsMatt Turner2012-09-051-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These calls allowed Xlib to use a custom memory allocator, but Xlib has used the standard C library functions since at least its initial import into git in 2003. It seems unlikely that it will grow a custom memory allocator. The functions now just add extra overhead. Replacing them will make future Coccinelle patches simpler. This patch has been generated by the following Coccinelle semantic patch: // Remove Xcalloc/Xmalloc/Xfree calls @@ expression E1, E2; @@ - Xcalloc (E1, E2) + calloc (E1, E2) @@ expression E; @@ - Xmalloc (E) + malloc (E) @@ expression E; @@ - Xfree (E) + free (E) @@ expression E; @@ - XFree (E) + free (E) Reviewed-by: Brian Paul <[email protected]>
* i965/blorp: Fix incorrect indentation.Paul Berry2012-09-051-2/+2
|
* i965: Don't use brw->fragment_program in the old brw_wm_pass2.c.Kenneth Graunke2012-09-051-1/+1
| | | | | | | | | | | | | | According to Eric, this shouldn't matter since we don't do precompiles using the old backend. In other words, brw->fragment_program (the currently active program) should equal c->fp (the program currently being compiled). However, it's just not a good idea to access brw->fragment_program directly in compiler code. It's totally illegal in the new backend, so let's just not do it here either. Signed-off-by: Kenneth Graunke <[email protected]> Reported-by: Paul Berry <[email protected]>
* meta: Don't save and restore fog state when there is no fog stateIan Romanick2012-09-031-2/+6
| | | | | | | | | | | | | I wonder if the better solution is to have _mesa_meta_GenerateMipmap not use MESA_META_ALL for the GLSL path. Even on compatibility profiles there is no reason to save and restore fog on this path. NOTE: This is a candidate for the 9.0 branch. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Tested-by: Lu Hua <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54295
* radeon: fix free/FREE mistakeBrian Paul2012-09-011-1/+1
|
* mesa: s/FREE/free/Brian Paul2012-09-0119-55/+55
| | | | | | | v2: replace instances in dri/common/ dirs Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: s/CALLOC/calloc/Brian Paul2012-09-018-17/+17
| | | | | | | v2: replace instances in dri/common/ dirs Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: s/MALLOC/malloc/Brian Paul2012-09-015-12/+12
| | | | | | | v2: replace instances in dri/common/ dirs Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Don't use brw->fragment_program in calculate_urb_setup().Kenneth Graunke2012-08-311-1/+1
| | | | | | | | | | | | | | | | | | Reading brw->fragment_program is nonsensical in compiler code: it contains the currently active program (if any), not the one currently being compiled. Attempting to access it may either lead to crashes (null pointer dereference if no program is active) or wrong results. Fixes piglit regressions since 9ef710575b914ddfc8e9a162d98ad554c1c217f7 on pre-Sandybridge hardware. The actual bug was created in commit 7b1fbc688999fd568e65211d79d7678562061594. NOTE: This is a candidate for the 9.0 and 8.0 branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54183 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* dri: Rework planar image interfaceJakob Bornecrantz2012-08-312-8/+153
| | | | | | | | | | | | | | | | | | | | | | As discussed with Kristian on #wayland. Pushes the decision of components into the dri driver giving it greater freedom to allow t to implement YUV samplers in hardware, and which mode to use. This interface will also allow drivers like SVGA to implement YUV surfaces without the need to sub-allocate and instead send 3 seperate buffers for each channel, currently not implemented. I have tested these changes on Gallium Svga. Scott tested them on both intel and Gallium Radeon. Kristan and Pekka tested them on intel. v2: Fix typo in dri2_from_planar. v3: Merge in intel changes. Tested-by: Scott Moreau <[email protected]> Tested-by: Pekka Paalanen <[email protected]> Tested-by: Kristian Høgsberg <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Signed-off-by: Jakob Bornecrantz <[email protected]>
* xmlconfig: use __progname when building for AndroidTapani Pälli2012-08-311-1/+1
| | | | | | | __progname symbol and strrchr are available with bionic. Signed-off-by: Tapani Pälli <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa: fix-up and use _mesa_delete_renderbuffer()Brian Paul2012-08-314-4/+4
| | | | | | | | _mesa_delete_renderbuffer() should free the mutex (though that may be a no-op) and then free the renderbuffer object itself. Subclasses of gl_renderbuffer can use this function too. Reviewed-by: José Fonseca <[email protected]>
* i965/msaa: flag _NEW_MULTISAMPLE in the brw_tracked_stateAnuj Phogat2012-08-302-2/+3
| | | | | | | This is required to get the program recompiled when SampleAlphaToCoverage is enabled. Reviewed-by: Paul Berry <[email protected]>
* meta: remove call to _meta_in_progress(), fix multisample enable/disableBrian Paul2012-08-301-2/+31
| | | | | | | | | | | | | | | | | | | This partially reverts d638da23d2ec2e9c52655b1ea138249e7f8bcccb. With gallium the meta code is not always built so the call to _meta_in_progress() was unresolved. Simply special-case the GL_MULTISAMPLE case in the meta code. There might be other special cases in the future given all the differences between legacy GL, core GL, GLES, etc. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=54234 and https://bugs.freedesktop.org/show_bug.cgi?id=54239 v2 (Paul Berry <[email protected]>): keep _meta_in_progress function, since it's needed by the i965 driver, but don't call it from core mesa. Signed-off-by: Brian Paul <[email protected]>
* meta: add parenthesis to silence compiler warningsBrian Paul2012-08-301-2/+2
| | | | Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Remove a dead member from live variables analysis.Eric Anholt2012-08-292-6/+0
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Initialize output_components[] by filling it with zeros.Kenneth Graunke2012-08-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Prior to commit 2f1869822, emit_fb_writes() looped from 0 to 3, writing all four components of a vec4 color output. However, that broke for smaller output types (float, vec2, or vec3). To fix that, I introduced a new variable (output_components[]) containing the size of the output type for each render target. Unfortunately, I forgot to actually initialize it in the constructor, which meant that unless a shader wrote to gl_FragColor, or the specific output for each render target, output_components would contain a garbage value, and we'd loop for a completely non-deterministic amount of time. Not actually emitting any color writes seems like the right approach. We may still need to emit a render target write (to terminate the thread), but don't have to put in any sensible values (the shader didn't write anything, after all). Fixes a regression since 2f18698220d8b27991fab550c4721590d17278e0. NOTE: This is a candidate for stable release branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54193 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]> Tested-by: Ian Romanick <[email protected]>
* i965: Allow creation of OpenGL 3.1 contextsIan Romanick2012-08-291-0/+19
| | | | | | | | v2: Fix API_OPENGL_CORE handling when TEXTURE_FLOAT_ENABLED is not defined. Based on review feedback from Eric Anholt. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Advertise GLSL 1.40 and TexBOs in core contextsIan Romanick2012-08-291-1/+9
| | | | Signed-off-by: Ian Romanick <[email protected]>
* intel: Clean up bits of cruft in intelCreateContextIan Romanick2012-08-291-40/+11
| | | | | | This and the previous three commits should probably be squashed together... Signed-off-by: Ian Romanick <[email protected]>
* i965: Set context flagsIan Romanick2012-08-293-2/+12
| | | | Signed-off-by: Ian Romanick <[email protected]>
* mesa/dri: Allow creation of forward-compatible contextsIan Romanick2012-08-291-5/+5
| | | | | | This is done by changing the API to API_OPENGL_CORE. Signed-off-by: Ian Romanick <[email protected]>
* mesa: Enable GL_{ARB,APPLE}_vertex_array_object in all driversIan Romanick2012-08-292-4/+0
| | | | | | | | This is a purely software extension. The drivers don't need to do any work to support it. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meta: Don't use deprecated keyword in 1.30 shaderIan Romanick2012-08-291-1/+1
| | | | Signed-off-by: Ian Romanick <[email protected]>
* mesa: Only FRONT_AND_BACK is allowed for PolygonMode in core contextIan Romanick2012-08-291-2/+8
| | | | | | | | | | | | | Page 407 (page 423 of the PDF) of the OpenGL 3.0 spec says (in the list of deprecated functionality): "Separate polygon draw mode - PolygonMode face values of FRONT and BACK; polygons are always drawn in the same mode, no matter which face is being rasterized." Also modify meta to not use FRONT or BACK in a core context. Signed-off-by: Ian Romanick <[email protected]>
* meta: Don't stray outside the confines of the API specified in the contextPaul Berry2012-08-291-42/+58
| | | | | Signed-off-by: Paul Berry <[email protected]> Signed-off-by: Ian Romanick <[email protected]>
* meta: Add GLSL variant of _mesa_meta_GenerateMipmap() functionAnuj Phogat2012-08-291-58/+220
| | | | | | | | | | | | | | | | This reduces the overhead of using the fixed function internally in the driver. V2: Use setup_glsl_generate_mipmap() and setup_ff_generate_mipmap() functions to avoid code duplication. Use glsl version when ARB_{vertex, fragmet}_shader are present. Remove redundant code. V3: Remove redundant border related code leaving the assertion. Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965: Disable the swrast context setup on GL 3.1 core.Eric Anholt2012-08-283-15/+34
| | | | | | | | | | | | | | I've reviewed the code, and the swrast callsites remaining are all in drawpixels/copypixels/bitmap/accum, or _swrast_BlitFramebuffer that shouldn't be hit. A piglit run with the context setup disabled on legacy GL and GLES2 showed regressions only in the copypixels and drawpixels tests. If the context type is forced, this reduces the shader_runner maximum heap size for glsl-algebraic-add-add-1.shader_test from 15,137,496b to 4,165,376b. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Replace general sw fallback support with a manual check for rendermode.Eric Anholt2012-08-285-120/+14
| | | | | | | There were no other cases that set it any more. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* intel: Move RenderMode fallback func to i915 driver.Eric Anholt2012-08-285-18/+20
| | | | | | | | The Fallback field of the context struct doesn't work that way on i965, and it's the only caller of FALLBACK() in the driver. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Drop the old sw fallback for position array being disabled.Eric Anholt2012-08-281-7/+0
| | | | | | | | | This code has been in the driver since the first commit. I think it was trying to stop rendering from happening with a disabled position array. Core mesa has since had changes to deal with disabled position arrays correctly. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Drop support for forcing drawing through sw fallbacks.Eric Anholt2012-08-282-5/+2
| | | | | | | It turns out it hasn't worked since at least 8.0. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Move depth resolve for span fallbacks to a simpler place.Eric Anholt2012-08-282-28/+3
| | | | | Reviewed-by: Chad Versace <[email protected]> Acked-by: Ian Romanick <[email protected]>
* i965: Drop manual hiz resolves in span rendering.Eric Anholt2012-08-281-10/+0
| | | | | | | | swrast uses MapRenderbuffer, which leads to intel_miptree_map, which does the depth resolve. Reviewed-by: Chad Versace <[email protected]> Acked-by: Ian Romanick <[email protected]>
* i965: Make VS programs obey the shader_precompile driconf option.Kenneth Graunke2012-08-271-1/+1
| | | | | | | | Now that it's on by default, we may as well make it obey the flag, for consistency's sake if nothing else. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Reenable the fragment shader precompile.Kenneth Graunke2012-08-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | Precompiling the shader at link time often allows us to avoid compiling it at the first use. This moves the expensive compilation and optimization process to game or level load time, rather than at draw time, where we really can't avoid any cycles and don't want to risk stalling the GPU. The downside is that we have to guess the non-orthagonal state the program will have set when it draws with the shader. Previously, we guessed wrong for nearly every shader, so it wasn't useful. With the recent SamplerUnits rework and this series, we've either eliminated state or made smarter guesses, and usually get it right now. In the L4D2 time demo, I now have 39 fragment shader recompiles and no vertex shader recompiles. Before this series and the SamplerUnits rework, I had 206 fragment shader recompiles and 192 vertex shader recompiles. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Set swizzle fields in the VS precompile program key.Kenneth Graunke2012-08-271-0/+11
| | | | | | | | | | | | | | | | | This fixes a regression since 76d1301e8e8e50dc962601a9977bc52148798349: I began setting SWIZZLE_XYZW for unused sampler units in the actual program keys, since this matched the FS precompile behavior. However, the VS precompile was expecting zero, so that commit made essentially every vertex shader (even those not using texturing) mismatch and need to be recompiled. Setting them in the VS precompile key solves the issue. It also is an improvement over our old behavior: previously we guessed that vertex shaders didn't use any textures at all. Now we actually look to see if the VS had any sampler uniforms and guess based on that. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/vs: Add VS program key dumping to INTEL_DEBUG=perf.Kenneth Graunke2012-08-273-1/+76
| | | | | | | Eric added support for WM key debugging. This adds it for the VS. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Assume shadow sampler swizzling is <X, X, X, 1>.Kenneth Graunke2012-08-271-2/+8
| | | | | | | | | | | | | | | | Our previous assumption, SWIZZLE_XYZW, was completely bogus for depth textures. There are no Y, Z, or W components. DEPTH_TEXTURE_MODE has three options: - GL_LUMINANCE: <X, X, X, 1> - GL_INTENSITY: <X, X, X, X> - GL_ALPHA: <0, 0, 0, X> The default value is GL_LUMINANCE, and most applications don't seem to alter DEPTH_TEXTURE_MODE. Make that our precompile guess. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Index sampler program key data by linker-assigned index.Kenneth Graunke2012-08-276-30/+30
| | | | | | | | | Now that most things are based on the linker-assigned index, it makes sense to convert the arrays in the VS/WM program key as well. It seems silly to leave them indexed by texture unit. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Only set proj_attrib_mask for fixed function.Kenneth Graunke2012-08-272-2/+12
| | | | | | | | | | | | | | brw_wm_prog_key's proj_attrib_mask field is designed to enable an optimization for fixed-function programs, letting us avoid projecting attributes where the divisor is 1.0. However, for shaders, this is not useful, and is pretty much impossible to guess when building the FS precompile key. Turning it off for shaders should allow the precompile to work and not lose much. Signed-off-by: Kenneth Graunke <[email protected]> Suggested-by: Eric Anholt <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Don't set stats_wm in the WM program key on Gen6+.Kenneth Graunke2012-08-271-1/+3
| | | | | | | It's only needed for Gen4/5 IZ lookup workarounds. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Don't set vp_outputs_written in the WM program key on Gen6+.Kenneth Graunke2012-08-272-5/+10
| | | | | | | It's only used by on pre-Sandybridge hardware. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Double the size of the state cache.Kenneth Graunke2012-08-271-2/+2
| | | | | | | | We probably want to do something more sophisticated here, but this at least makes it through L4D2 without dumping the program cache. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Move hiz resolve to after renderbuffer resizing (v2)Chad Versace2012-08-271-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Do all pre-draw hiz resolves *after* the renderbuffers are resized by intel_prepare_render. Otherwise, we may resolve buffers that are immediately discarded afterwards. Fixes the assertion failure below when resizing windows in KDE and under some unknown circumstance in Chrome OS: intel_resolve_map.c:46: intel_resolve_map_set: Assertion `(*tail)->need == need' failed. Also, remove the comment that "resolves must occur [...] before setting up any hardware state". That was true when resolves were implemented with meta-ops, but no longer with blorp. v2: - Keep brw_predraw_resolve_buffers in its current position, which is before any brw_context bits are modified. Instead, move the call to intel_prepare_render. Note: This is a candiate for the 8.0 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52252 Reported-by: Lu Hua <[email protected]> Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965: Remove redundant null checkChad Versace2012-08-271-2/+1
| | | | | | | | intel_renderbuffer_resolve_hiz checks if rb->mt is null, so there is no need for the caller to do so. Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965: Rewrite the comment describing the query object support.Eric Anholt2012-08-261-10/+12
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen6+: Add support for GL_ARB_timer_query.Eric Anholt2012-08-264-0/+62
| | | | | | Needs updated libdrm. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add support for GL_ARB_occlusion_query2.Eric Anholt2012-08-261-0/+1
| | | | | | | This extension is just a bit of core code on top of the GL_ARB_occlusion_query support. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Fix accumulator_contains() test to also reject swizzles of the dst.Eric Anholt2012-08-261-1/+1
| | | | | | | | | | | | | | When faced with this sequence: MOV R1, c[1]; MAD R0, R2, R1.x, R1.y; we were concluding that the MOV of R1 set up our accumulator and so we could just use the previous result. Only, it's got R1.xyzw in it instead of the r1.y we're looking for. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46784 NOTE: This is a candidate for the 8.0 branch.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 20:35:12 +0000