summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Ensure stack is realigned on x86.José Fonseca2014-12-051-0/+3
| | | | | | | | | | | | | | | | | | | | Nowadays GCC assumes stack pointer is 16-byte aligned even on 32-bits, but that is an assumption OpenGL drivers (or any dynamic library for that matter) can't afford to make as there are many closed- and open- source application binaries out there that only assume 4-byte stack alignment. This fix uses force_align_arg_pointer GCC attribute, and is only a stop-gap measure. The right fix would be to pass -mstackrealign or -mincoming-stack-boundary=2 to all source fails that use any -msse* option, as there is no way to guarantee if/when GCC will decide to spill SSE registers to the stack. https://bugs.freedesktop.org/show_bug.cgi?id=86788 Reviewed-by: Brian Paul <[email protected]>
* util/primconvert: Avoid point arithmetic; apply offset on all cases.José Fonseca2014-12-051-1/+2
| | | | | | Matches what u_vbuf_get_minmax_index() does. Reviewed-by: Ilia Mirkin <[email protected]>
* util/primconvert: take ib offset into accountIlia Mirkin2014-12-051-1/+1
| | | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.4 10.3" <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Rob Clark <[email protected]>
* util/primconvert: support instanced renderingIlia Mirkin2014-12-051-0/+2
| | | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.3 10.4" <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Rob Clark <[email protected]>
* util/primconvert: pass index bias throughIlia Mirkin2014-12-051-0/+1
| | | | | | | | | | The index_bias (aka base_vertex) applies to the downstream draw just as much, since the actual index values are never modified. Signed-off-by: Ilia Mirkin <[email protected]> Cc: "10.3 10.4" <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Rob Clark <[email protected]>
* i965: Compute VS attribute WA bits earlier and check if they changed.Kenneth Graunke2014-12-044-37/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BRW_NEW_VERTICES is flagged every time we draw a primitive. Having the brw_vs_prog atom depend on BRW_NEW_VERTICES meant that we had to compute the VS program key and do a program cache lookup for every single primitive. This is painfully expensive. The workaround bit computation is almost entirely based on the vertex attribute arrays (brw->vb.inputs[i]), which are set by brw_merge_inputs. The only thing it uses the VS program for is to see which VS inputs are actually read. brw_merge_inputs() happens once per primitive, and can safely look at the currently bound vertex program, as it doesn't change in the middle of a draw. This patch moves the workaround bit computation to brw_merge_inputs(), right after assigning brw->vb.inputs[i], and stores the previous WA bit values in the context. If they've actually changed from the last draw (which is uncommon), we signal that we need a new vertex program, causing brw_vs_prog to compute a new key. Improves performance in Gl32Batch7 by 13.6123% +/- 0.739652% (n=166) on Haswell GT3e. I'm told Baytrail shows similar gains. v2: Introduce a new BRW_NEW_VS_ATTRIB_WORKAROUNDS dirty bit, rather than reusing BRW_NEW_VERTEX_PROGRAM (suggested by Chris Forbes). This prevents unnecessary re-emission of surface/sampler related atoms (and an SOL atom on Sandybridge). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* egl/dri2: Log a warning if no platforms are enabled.Matt Turner2014-12-041-0/+1
| | | | | | | | | If you hit this, you didn't compile with --with-egl-platforms=... Recompile with something like --with-egl-platforms=x11,drm and make clean and make again. Reviewed-by: Anuj Phogat <[email protected]>
* i965: Drop BRW_NEW_VERTEX_PROGRAM and _NEW_TRANSFORM from Gen4 VS state.Kenneth Graunke2014-12-041-3/+2
| | | | | | | | | | These stopped being necessary in commit ab973403e445cd8211dba4e87e0. v2: Update commit message with a better explanation (thanks to Eric Anholt for doing the git archaeology). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Drop BRW_NEW_VERTEX_PROGRAM from Gen7+ 3DSTATE_VS atoms.Kenneth Graunke2014-12-042-2/+0
| | | | | | | | | | | We don't access brw->vertex_program or ctx->_Shader since the previous commit, so we don't need this dirty bit. I think it's still necessary on Gen6 because it still conflates constant uploading with unit state uploading. We can fix that later. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Store floating point mode choice in brw_stage_prog_data.Kenneth Graunke2014-12-0411-43/+18
| | | | | | | | | | | | | | | | | | | | | | | | We use IEEE mode for GLSL programs, but need to use ALT mode for ARB programs so that 0^0 == 1. The choice is based entirely on the shader source language. Previously, our code to determine which mode we wanted was duplicated in 8 different places (VS and FS for Gen4-5, Gen6, Gen7, and Gen8). The ctx->_Shader->CurrentProgram[stage] == NULL check was confusing as well - we use CurrentProgram (non-derived state), but _Shader (derived state). It also relies on knowing that ARB programs don't use gl_shader_program structures today. The compiler already makes this assumption in a few places, but I'd rather keep that assumption out of the state upload code. With this patch, we select the mode at compile time, and store that choice in prog_data. The state upload code simply uses that decision. This eliminates a BRW_NEW_*_PROGRAM dependency in the state upload code. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Make Gen4-5 and Gen8+ ALT checks use ctx->_Shader too.Kenneth Graunke2014-12-044-4/+4
| | | | | | | | | | | | | Commit c0347705 changed the Gen6-7 code to use ctx->_Shader rather than ctx->Shader, but neglected to change the Gen4-5 or Gen8+ code. This might fix SSO related bugs, but ALT mode is only used for ARB programs, so if there's an actual problem, it's likely no one would run into it. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Move PSCDEPTH calculations from draw time to compile time.Kenneth Graunke2014-12-046-52/+40
| | | | | | | | | | | | | | | The "Pixel Shader Computed Depth Mode" value is entirely based on the shader program, so we can easily do it at compile time. This avoids the if+switch on every 3DSTATE_WM (Gen7)/3DSTATE_PS_EXTRA (Gen8+) upload, and shares a bit more code. This also simplifies the PMA stall code, making it match the formula more closely, and drops a BRW_NEW_FRAGMENT_PROGRAM dependency. (Note that the previous comment was wrong - the code and the documentation have != PSCDEPTH_OFF, not ==.) Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* freedreno/a4xx: unify vertex/texture formats into a single tableRob Clark2014-12-041-299/+180
| | | | | | Similar to the scheme that Ilia put in place for a3xx. Signed-off-by: Rob Clark <[email protected]>
* freedreno/a4xx: fd4_util -> fd4_formatRob Clark2014-12-0415-15/+15
| | | | Signed-off-by: Rob Clark <[email protected]>
* freedreno: update generated headers / a4xx fmt renameRob Clark2014-12-046-124/+124
| | | | Signed-off-by: Rob Clark <[email protected]>
* i965: Add var->location != -1 assertions.Kenneth Graunke2014-12-032-0/+3
| | | | | | | | | | We shouldn't receive variables with invalid locations set - adding these assertions should help catch problems before they cause crashes later. Inspired by similar code in st_glsl_to_tgsi. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/fs: Don't offset uniform registers in half().Matt Turner2014-12-031-0/+4
| | | | | | | Half gives you the second half of a SIMD16 register, but if the register is a uniform it would incorrectly give you the next register. Reviewed-by: Jason Ekstrand <[email protected]>
* freedreno/a4xx: frag-depth fixesRob Clark2014-12-032-18/+24
| | | | | | Also seems to fix kill/discard. Signed-off-by: Rob Clark <[email protected]>
* linker: Assign varying locations geometry shader inputs for SSOIan Romanick2014-12-031-0/+15
| | | | | | | | | | Previously only geometry shader outputs would be assigned locations if the geometry shader was the only stage in the linked program. Signed-off-by: Ian Romanick <[email protected]> Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82585 Reviewed-by: Jordan Justen <[email protected]>
* linker: Wrap access of producer_var with a NULL checkIan Romanick2014-12-031-3/+5
| | | | | | | | | | | | producer_var could be NULL if consumer_var is not NULL and consumer_is_fs is false. This will occur when the producer is NULL and the consumer is the geometry shader for a program that contains only a geometry shader. This will occur starting with the next patch. Signed-off-by: Ian Romanick <[email protected]> Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82585 Reviewed-by: Jordan Justen <[email protected]>
* st/xvmc: Fix compiler warningsJan Vesely2014-12-033-6/+6
| | | | | | | Mostly signed/unsigned comparison Signed-off-by: Jan Vesely <[email protected]> Reviewed-by: Christian König <[email protected]>
* st/nine: Fix vertex declarations for non-standard (usage/index)Axel Davy2014-12-037-108/+89
| | | | | | | | | | | | | | | | | | | | Nine code to match vertex declaration to vs inputs was limiting the number of possible combinations. Some sm3 games have issues with that, because arbitrary (usage/index) can be used. This patch does the following changes to fix the problem: . Change the numbers given to (usage/index) combinations to uint16 . Do not put limits on the indices when it doesn't make sense . change the conversion rule (usage/index) -> number to fit all combinations . Instead of having a table usage_map mapping a (usage/index) number to an input index, usage_map maps input indices to their (usage/index) Cc: "10.4" <[email protected]> Tested-by: Yaroslav Andrusyak <[email protected]> Acked-by: Ilia Mirkin <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* st/nine: sm1_declusage_to_tgsi, do not restrict indices with ↵Axel Davy2014-12-031-60/+52
| | | | | | | | | | | | | | | | | | | | TGSI_SEMANTIC_GENERIC With sm3, you can declare an input/output with an usage and an usage index. Nine code hardcodes the translation usage/index to a corresponding TGSI code. The translation was limited to a few usage/index combinations that were corresponding to most of the needs of games, but some games did not work. This patch rewrites that Nine code to map all possible usage/index combination to TGSI code. The index associated to TGSI_SEMANTIC_GENERIC doesn't need to be low for good performance, as the old code was supposing, and is not particularly bounded (it's UINT16). Given the index is BYTE, we can map all combinations. Cc: "10.4" <[email protected]> Tested-by: Yaroslav Andrusyak <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* st/nine: Queries: Always return D3D_OK when issuing with D3DISSUE_BEGINAxel Davy2014-12-031-1/+6
| | | | | | | | This is the behaviour that Wine tests. Reviewed-by: David Heidelberg <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* st/nine: Queries: always succeed for D3DQUERYTYPE_TIMESTAMP when flushingAxel Davy2014-12-031-0/+3
| | | | | | | | This is the behaviour that Wine tests Tested-by: David Heidelberg <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* st/nine: Queries: allow app to call GetData without Issuing firstAxel Davy2014-12-031-4/+9
| | | | | | | | Nine was allowing that behaviour, but was not filling the result. Tested-by: David Heidelberg <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* st/nine: Queries: Fix D3DISSUE_END behaviour.Axel Davy2014-12-031-4/+6
| | | | | | | | | | | | | | | | | Issuing D3DISSUE_END should: . reset previous queries if possible . end the query Previous behaviour wasn't calling end_query for queries not needing D3DISSUE_BEGIN, nor resetting previous queries. This fixes several applications not launching properly. Cc: "10.4" <[email protected]> Tested-by: David Heidelberg <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* st/nine: Queries: return S_FALSE instead of INVALIDCALL when in building ↵Axel Davy2014-12-031-1/+4
| | | | | | | | | | query state It is the same behaviour as wine has. Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: David Heidelberg <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* st/nine: Queries: Use gallium caps to get if queries are supported. (v2)Axel Davy2014-12-033-23/+24
| | | | | | | | | | | | Some queries need the driver to advertise a cap to be supported. For example r300 doesn't support them. v2 (David): check also for PIPE_CAP_QUERY_PIPELINE_STATISTICS, fix wine tests on r300g Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: David Heidelberg <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* st/nine: Queries: Remove flush logicAxel Davy2014-12-032-9/+5
| | | | | | | get_query_result flushes automatically, we don't need to flush. Reviewed-by: Ilia Mirkin <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* st/nine: Queries: remove dummy queriesAxel Davy2014-12-032-94/+12
| | | | | | | | | | | | | | | | Applications are supposed to call CreateQuery with a NULL ppQuery to know if the query is supported. We supported that. However when ppQuery was not NULL, we were accepting to create the query and were creating a dummy query even when the query is not supported. Wine has different behaviour. This patch drops the dummy queries support and matches wine behaviour. Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: David Heidelberg <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* freedreno/a3xx: implement anisotropic filteringIlia Mirkin2014-12-031-4/+6
| | | | Signed-off-by: Ilia Mirkin <[email protected]>
* freedreno/a4xx: rect texturesRob Clark2014-12-031-3/+4
| | | | Signed-off-by: Rob Clark <[email protected]>
* freedreno: update generated headersRob Clark2014-12-035-11/+34
| | | | Signed-off-by: Rob Clark <[email protected]>
* freedreno: fix signed vs unsigned lolsRob Clark2014-12-031-1/+1
| | | | Signed-off-by: Rob Clark <[email protected]>
* gallivm: Update for RTDyldMemoryManager becoming an unique_ptr.José Fonseca2014-12-031-0/+4
| | | | | | Trivial. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=86958
* glsl: throw error when using invariant(all) in a fragment shaderTapani Pälli2014-12-031-1/+12
| | | | | | | | Note that some of the GLSL specifications explicitly state this as compile error, some simply state that 'it is an error'. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965/skl: Fix SBE state upload code.Ben Widawsky2014-12-021-1/+3
| | | | | | | | | | | | | | | | | | | | | | | The state upload code was incorrectly shifting the attribute swizzles. The effect of this is we're likely to get the default swizzle values, which disables the component. This doesn't technically fix any bugs since Skylake support is still disabled by default (no PCI IDs). While here, since VARYING_SLOT_MAX can be greater than the number of attributes we have available, add a warning to the code to make sure we never do the wrong thing (and hopefully prevent further static analysis from finding this). Admittedly I am a bit confused. It seems to me like the moment a user has greater than 8 varyings we will hit this condition. CC Ken to clarify. v2: Forgot to git add the warning message in v1 v3: Change the > 31 varyings to an assertion (Ken) Reported-by: Ilia Mirkin <[email protected]> (via Coverity) Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* r600, llvm: Don't leak global symbol offsetsJan Vesely2014-12-021-0/+1
| | | | | Signed-off-by: Jan Vesely <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* i965: Avoid union literal, for old gcc compatibility.Matt Turner2014-12-021-1/+2
| | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86939 Reviewed-by: Ian Romanick <[email protected]>
* i965: Remove tabs from instruction scheduler.Matt Turner2014-12-021-98/+98
| | | | Reviewed-by: Ben Widawsky <[email protected]>
* i965/vs: Set brw_vs_prog_key::clamp_vertex_color to 0 when irrelevant.Kenneth Graunke2014-12-021-3/+8
| | | | | | | | | | | | | | | | Vertex color clamping is only relevant if the shader writes to the built-in gl_[Secondary]{Front,Back}Color varyings. Otherwise, brw_vs_prog_key::clamp_vertex_color is never used, so we can simply leave it set to 0. This enables us to correctly predict the clamp_vertex_color key value in the precompile for shaders which don't use those varyings. Eliminates virtually all VS recompiles in Serious Sam 3's intro. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Make vertex color clamp handling code VS specific.Kenneth Graunke2014-12-025-12/+12
| | | | | | | | | | | | | Vertex color clamping only applies to gl_[Secondary]{Front,Back}Color, which are compatibility-only built-in varyings. We only support GS in core profile, so they can't exist in geometry shaders. We can drop several dirty bits from the GS program key - they're unnecessary for a core profile implementation. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965/vs: Handle vertex color clamping in emit_urb_slot().Kenneth Graunke2014-12-022-11/+13
| | | | | | | | | | | | | Vertex color clamping only applies to a few specific built-ins: COL0/1 and BFC0/1 (aka gl_[Secondary]{Front,Back}Color). It seems weird to handle special cases in a function called emit_generic_urb_slot(). emit_urb_slot() is all about handling special cases, so it makes more sense to handle this there. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Use the enum type for gen6_gather_wa sampler key field.Kenneth Graunke2014-12-021-7/+7
| | | | | | | Requested by Matt Turner. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Drop use of GL types in program keys.Kenneth Graunke2014-12-021-23/+23
| | | | | | | | This is really far removed from the API; we should just use C types. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Move program key structures to brw_program.h.Kenneth Graunke2014-12-025-82/+103
| | | | | | | | | | | | | | With fs_visitor/fs_generator being reused for SIMD8 VS/GS programs, we're running into weird #include patterns, where scalar code #includes brw_vec4.h and such. Program keys aren't really related to SIMD4X2/SIMD8 execution - they mostly capture NOS for a particular shader stage. Consolidating them all in one place that's vec4/scalar neutral should help avoid problems. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Delete brw_state_flags::cache and related code.Kenneth Graunke2014-12-0234-82/+4
| | | | | | | | | It's been merged into brw_state_flags::brw for simplicity and efficiency. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Move BRW_NEW_*_PROG_DATA flags to .brw (not .cache).Kenneth Graunke2014-12-0234-115/+137
| | | | | | | | | | | | | | | | | | | | | | I put the BRW_NEW_*_PROG_DATA flags at the beginning so that brw_state_cache.c can still continue using 1 << brw_cache_id. I also added a comment explaining the difference between BRW_NEW_*_PROG_DATA and BRW_NEW_*_PROGRAM, as it took me a long time to remember it. Non-mechanical changes: - brw_state_cache.c and brw_ff_gs.c now signal .brw, not .cache. - brw_state_upload.c - INTEL_DEBUG=state changes. - brw_context.h - bit definition merging. v2: Correct the explanation of BRW_NEW_*_PROG_DATA to mention state-based recompiles, and nix the "proper subset" claim, as it's false. (Caught by Kristian Høgsberg). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Rename CACHE_NEW_*_PROG to BRW_NEW_*_PROG_DATA.Kenneth Graunke2014-12-0233-124/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we've moved a bunch of CACHE_NEW_* bits to BRW_NEW_*, the only ones that are left are legitimately related to the program cache. Yet, it seems a bit wasteful to have an entire bitfield for only 7 bits. State upload is one of the hottest paths in the driver. For each atom in the list, we call check_state() to see if it needs to be emitted. Currently, this involves comparing three separate bitfields (mesa, brw, and cache). Consolidating the brw and cache bitfields would save a small amount of CPU overhead per atom. Broadwell, for example, has 57 state atoms, so this small savings can add up. CACHE_NEW_*_PROG covers the brw_*_prog_data structures, as well as the offset into the program cache BO (prog_offset). Since most uses refer to brw_*_prog_data, I decided to use BRW_NEW_*_PROG_DATA as the name. Removing "cache" completely is a bit painful, so I decided to do it in several patches for easier review, and to separate mechanical changes from manual ones. This one simply renames things, and was made via: $ for file in *.[ch]; do sed -i -e 's/CACHE_NEW_\([A-Z_\*]*\)_PROG/BRW_NEW_\1_PROG_DATA/g' \ -e 's/BRW_NEW_WM_PROG_DATA/BRW_NEW_FS_PROG_DATA/g' $file done Note that BRW_NEW_*_PROG_DATA is still in .cache, not .brw! The next patch will remedy this flaw. It will also fix the alphabetization issues. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Acked-by: Matt Turner <[email protected]>