summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* i965: Eliminate brw->vs.prog_data pointer.Kenneth Graunke2016-10-0518-96/+121
| | | | | | | | | | | | Just say no to: - brw->vs.base.prog_data = &brw->vs.prog_data->base.base; We'll just use the brw_stage_prog_data pointer in brw_stage_state and downcast it to brw_vs_prog_data as needed. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i965: Introduce downcast helpers for prog_data structures.Kenneth Graunke2016-10-057-62/+66
| | | | | | | Similar to brw_context(...), intel_texture_object(...), and so on. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i965/sync: Rename awkward variableChad Versace2016-10-051-6/+6
| | | | | | | | | | What is the difference between a 'driver_fence' and a 'fence'? Do the characters 'driver_' add anything helpful? Nope. They do, though, add an extra 7 chars and pull your eyeballs away to ask "huh? what's that?" one microsecond too many. Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/sync: Rename intel_syncobj.c -> brw_sync.cChad Versace2016-10-053-2/+2
| | | | | Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/sync: Replace 'intel' prefix with 'brw'Chad Versace2016-10-053-37/+37
| | | | | | | This is yet another patch for the great renaming begun long ago. Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/sync: Fix uninitalized usage and leak of mutexChad Versace2016-10-051-2/+12
| | | | | | | | | | | | | | | | | We locked an unitialized mutex in the callstack glClientWaitSync intel_gl_client_wait_sync brw_fence_client_wait_sync because we forgot to initialize it in intel_gl_fence_sync. (The EGLSync codepath didn't have this bug. It initialized the mutex in intel_dri_create_sync). We also forgot to tear down (mtx_destroy) the mutex when destroying the sync object. Cc: [email protected] Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: enable GL_KHR_robustnessNicolai Hähnle2016-10-051-0/+2
| | | | | | | | | | | | The difference to the virtually identical ARB_robustness (which is already enabled unconditionally) is miniscule and handled elsewhere, but this cap seems like the right thing to require for this extension. v2: drop the device reset cap requirement (Ilia) Reviewed-by: Marek Olšák <[email protected]> (v1) Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Edward O'Callaghan <[email protected]>
* st/mesa: set a device reset callback when availableNicolai Hähnle2016-10-054-2/+38
| | | | | Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: extract conversion from pipe_reset_status to GLenumNicolai Hähnle2016-10-051-11/+18
| | | | | Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* i965: use L3 data cache for SSBOsLionel Landwerlin2016-10-051-1/+2
| | | | | | | | | | | | | Anv programs the hardware to use L3 data cache if we use either SSBOs or images in the shaders, we can program i965 the same way. gl_shader_program has a bit of a confusing named field with 'NumAtomicBuffers'. It doesn't tell how many buffers are accessed by the shader in an atomic way but instead the number of atomic counters manipulated by the shader. Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* mesa: Raise INVALID_ENUM in FramebufferTexture*D for unknown textargets.Kenneth Graunke2016-10-041-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ES3-CTS.functional.negative_api.buffer.framebuffer_texture2d expects glFramebufferTexture[123]D to raise GL_INVALID_ENUM when supplied a completely bogus textarget parameter (i.e. 0xffffffff). This is at odds with the spec. GLES 3.1 says: "An INVALID_OPERATION error is generated if texture is not zero and textarget is not one of TEXTURE_2D, TEXTURE_2D_MULTISAMPLE, or one of the cube map face targets from table 8.21." (and GLES 3.0 and GL 4.5 both have similar text). However, GL has a general guideline that says: "If a command that requires an enumerated value is passed a symbolic constant that is not one of those specified as allowable for that command, an INVALID_ENUM error is generated." Apparently other vendors reconcile these two rules as follows: GL should raise INVALID_OPERATION for actual texture target enumeration values which are not allowed for this particular glFramebufferTexture*D call. Any value that is not a texture target should result in GL_INVALID_ENUM. For example, glFramebufferTexture2D with GL_TEXTURE_1D would result in INVALID_OPERATION because it is a real texture target, but not allowed for the 2D version of the function. But calling it with GL_FRONT would result in INVALID_ENUM, as that isn't even a texture target. Fixes: - {ES3-CTS,dEQP-GLES3}.functional.negative_api.buffer.framebuffer_texture2d - {ES31-CTS,ES32-CTS,dEQP-GLES31}.functional.debug.negative_coverage.get_error.buffer.framebuffer_texture2d References: https://gitlab.khronos.org/opengl/cts/merge_requests/387 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: Reorganize check_textarget().Kenneth Graunke2016-10-041-43/+37
| | | | | | | | Having one top-level switch statement covering all known texture targets will make the next change easier to implement. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i965: Drop _NEW_TRANSFORM from 3DSTATE_VS atom on Gen7.Kenneth Graunke2016-10-041-1/+1
| | | | | | | | | | | | | | The atom that uploads push constants listens to _NEW_TRANSFORM for legacy clip plane handling. On Sandybridge, the gen6_vs_state atom emits 3DSTATE_CONSTANT_VS as well as 3DSTATE_VS, so it needs to listen to the same set of conditions. However, it looks like Gen7 doesn't need this. The push constant atom emits 3DSTATE_CONSTANT_VS directly, and the gen7_vs_state atom that emits 3DSTATE_VS doesn't have a dependency on ctx->Transform. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Fix brw_clear_cache to clean up TCS/TES shaders.Kenneth Graunke2016-10-041-0/+2
| | | | | | | We need to free prog_data for TCS/TES too. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i965: Add missing BRW_CS_PROG_DATA to CS work group surface atom.Kenneth Graunke2016-10-041-2/+5
| | | | | | Cc: [email protected] Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Add missing BRW_NEW_CS_PROG_DATA to compute constant atom.Kenneth Graunke2016-10-041-1/+2
| | | | | | | | | CACHE_NEW_CS_PROG hasn't existed in quite a long time...the old comment was there, but not the actual bit. Cc: [email protected] Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Add missing BRW_NEW_FS_PROG_DATA to render target reads.Kenneth Graunke2016-10-041-1/+3
| | | | | | Cc: [email protected] Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Move BRW_NEW_FRAGMENT_PROGRAM from 3DSTATE_PS to PS_EXTRA.Kenneth Graunke2016-10-041-1/+1
| | | | | | | | | 3DSTATE_PS doesn't need this. 3DSTATE_PS_EXTRA however does, for brw_color_buffer_write_enabled(). Cc: [email protected] Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Add missing BRW_NEW_VS_PROG_DATA to 3DSTATE_CLIP.Kenneth Graunke2016-10-041-0/+2
| | | | | | Cc: [email protected] Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Fix missing _NEW_TRANSFORM in Gen8+ 3DSTATE_DS atom.Kenneth Graunke2016-10-041-1/+2
| | | | | | | | | Needed for user clip plane enables. Broken since this code was introduced. Cc: [email protected] Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Enable ARB_shader_atomic_counter_opsIan Romanick2016-10-044-6/+50
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: Refactor emission of atomic counter operationsIan Romanick2016-10-044-30/+27
| | | | | | | This will make it easier to add more operations. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* glsl: Kill __intrinsic_atomic_subIan Romanick2016-10-041-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just generate an __intrinsic_atomic_add with a negated parameter. Some background on the non-obvious reasons for the the big change to builtin_builder::call()... this is cribbed from some discussion with Ilia on mesa-dev. Why change builtin_builder::call() to allow taking dereferences and create them here rather than just feeding in the ir_variables directly? The problem is the neg_data ir_variable node would have to be in two lists at the same time: the instruction stream and parameters. The ir_variable node is automatically added to the instruction stream by the call to make_temp. Restructuring the code so that the ir_variables could be in parameters then move them to the instruction stream would have been pretty terrible. ir_call in the instruction stream has an exec_list that contains ir_dereference_variable nodes. The builtin_builder::call method previously took an exec_list of ir_variables and created a list of ir_dereference_variable. All of the original users of that method wanted to make a function call using exactly the set of parameters passed to the built-in function (i.e., call __intrinsic_atomic_add using the parameters to atomicAdd). For these users, the list of ir_variables already existed: the list of parameters in the built-in function signature. This new caller doesn't do that. It wants to call a function with a parameter from the function and a value calculated in the function. So, I changed builtin_builder::call to take a list that could either be a list of ir_variable or a list of ir_dereference_variable. In the former case it behaves just as it previously did. In the latter case, it uses (and removes from the input list) the ir_dereference_variable nodes instead of creating new ones. text data bss dec hex filename 6036395 283160 28608 6348163 60dd83 lib64/i965_dri.so before 6036923 283160 28608 6348691 60df93 lib64/i965_dri.so after Signed-off-by: Ian Romanick <[email protected]> Acked-by: Ilia Mirkin <[email protected]>
* glsl: Use the ir_intrinsic_* enums instead of the __intrinsic_* name stringsIan Romanick2016-10-041-116/+171
| | | | | | | | | | | | | | text data bss dec hex filename 6038043 283160 28608 6349811 60e3f3 lib64/i965_dri.so before 6036507 283160 28608 6348275 60ddf3 lib64/i965_dri.so after v2: s/ir_intrinsic_atomic_sub/ir_intrinsic_atomic_counter_sub/. Noticed by Ilia. v3: Silence unhandled enum in switch warnings in st_glsl_to_tgsi. Signed-off-by: Ian Romanick <[email protected]> Acked-by: Ilia Mirkin <[email protected]>
* i965: fix unused variable warning in brw_emit_gpgpu_walker()Timothy Arceri2016-10-051-2/+1
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: add MAYBE_UNUSED to assert paramTimothy Arceri2016-10-051-1/+1
| | | | | | Fixes unused variable warning in release build. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: wrap unused function in #ifndef NDEBUGTimothy Arceri2016-10-051-0/+2
| | | | | | | This function is only ever used by an assert() this fixes an unused function warning in release builds. Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: fix unused variable warning in gen7_block_read_scratch()Timothy Arceri2016-10-051-2/+1
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* i965: add MAYBE_UNUSED to assert paramTimothy Arceri2016-10-051-1/+1
| | | | | | This fixes an unused variable warning on release builds. Reviewed-by: Iago Toral Quiroga <[email protected]>
* anv/gen7: Make use of local variable prog_dataAnuj Phogat2016-10-041-2/+2
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/gen8+: Enable GL_OES_viewport_arrayAnuj Phogat2016-10-042-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch causes 2 regressions in khronos' gles cts tests on various intel platforms. Failing tests: ES3-CTS.functional.state_query.integers.viewport_getinteger ES3-CTS.functional.state_query.integers.viewport_getfloat Here is an explanation of what's causing the failures: CTS tests are not clamping the x, y location of the viewport's bottom-left corner as recommended by ARB_viewport_array and OES_viewport_array: "The location of the viewport's bottom-left corner, given by (x,y), are clamped to be within the implementation-dependent viewport bounds range. The viewport bounds range [min, max] tuple may be determined by calling GetFloatv with the symbolic constant VIEWPORT_BOUNDS_RANGE_OES" Khronos CTS merge request to fix the test case: https://gitlab.khronos.org/opengl/cts/merge_requests/399 V2: Initialize the relevant variables for GL_OES_viewport_array on gen8+ Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* mesa: Add a check for OES_viewport_arrayAnuj Phogat2016-10-041-1/+3
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* mesa: Enable enums for OES_viewport_arrayAnuj Phogat2016-10-042-4/+10
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* i965: Only emit 1 viewport when possible.Kenneth Graunke2016-10-0310-30/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | In core profile, we support up to 16 viewports. However, in the majority of cases, only 1 of them is actually used - we only need the others if the last shader stage prior to the rasterizer writes gl_ViewportIndex. Processing all 16 viewports adds additional CPU overhead, which hurts CPU-intensive workloads such as Glamor. This meant that switching to core profile actually penalized Glamor to an extent, which is unfortunate. This patch tracks the number of relevant viewports, switching between 1 and ctx->Const.MaxViewports if gl_ViewportIndex is written. A new BRW_NEW_VIEWPORT_COUNT flag tracks this. This could mean re-emitting viewport state when switching, but hopefully this is offset by doing 1/16th of the work in the common case. The new flag is also lighter weight than BRW_NEW_VUE_MAP_GEOM_OUT, which we were using in one case. According to Eric Anholt, x11perf -copypixwin10 performance improves by 11.5094% +/- 3.10841% (n=10) on his Skylake. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i965: rename max_ds_* variable to max_tes_*Timothy Arceri2016-10-034-5/+5
| | | | | | Using consistent naming allows us to create macros more easily. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: rename max_hs_* variables to max_tcs_*Timothy Arceri2016-10-034-5/+5
| | | | | | Using consistent naming allows us to create macros more easily. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Drop pointless stage == MESA_SHADER_FRAGMENT checks.Kenneth Graunke2016-10-021-5/+1
| | | | | | | There's an assert right above this. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: use uint32_t rather than unsigned for xfb struct membersTimothy Arceri2016-10-011-10/+10
| | | | | | | These structs will be written to disk as part of the shader cache so use uint32_t just to be safe. Reviewed-by: Jason Ekstrand <[email protected]>
* i915/i965: remove commented out warningTimothy Arceri2016-10-012-6/+2
| | | | | | | The warning was also the wrong location, it should have been in the else. Reviewed-by: Ian Romanick <[email protected]>
* mesa: move _mesa_valid_to_render() to api_validate.cBrian Paul2016-09-305-191/+195
| | | | | | | Almost all of the other drawing validation code is in api_validate.c so put this function there as well. Reviewed-by: Anuj Phogat <[email protected]>
* i965: Remove useless (harmful) assertionBen Widawsky2016-09-281-1/+1
| | | | | | | | | The code already skips doing the depth stall on gen >= 8, and as we enable new platforms this assertion will fail needlessly. Instead of changing the caller, make this simple change. Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* glsl: don't crash when dumping shaders if some come from cacheTimothy Arceri2016-09-282-6/+17
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: enable ARB_ES3_2_compatibility when enough availableIlia Mirkin2016-09-271-0/+20
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Acked-by: Marek Olšák <[email protected]>
* st/mesa: enable GL_ANDROID_extension_pack_es31a when availableIlia Mirkin2016-09-271-0/+18
| | | | | | | For now that's never since advanced blend hasn't been piped through. Signed-off-by: Ilia Mirkin <[email protected]> Acked-by: Marek Olšák <[email protected]>
* i965: create populate key functions for tcs and tesTimothy Arceri2016-09-274-68/+88
| | | | | | These will be used by the on disk shader cache. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: make gs key generation helper available to shader cacheTimothy Arceri2016-09-272-1/+5
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: make vs and fs key generation helpers available to shader cacheCarl Worth2016-09-274-2/+10
| | | | | Signed-off-by: Timothy Arceri <[email protected]> Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
* mesa/st: support lowering multi-planar YUVRob Clark2016-09-2613-4/+239
| | | | | | | | | | | | | | | Support multi-planar YUV for external EGLImage's (currently just in the dma-buf import path) by lowering to multiple texture fetch's for each plane and CSC in shader. There was some discussion of alternative approaches for tracking the additional UV or U/V planes: https://lists.freedesktop.org/archives/mesa-dev/2016-September/127832.html They all seemed worse than pipe_resource::next Signed-off-by: Rob Clark <[email protected]>
* mesa/st: add nir pass to lower tex_src_planeRob Clark2016-09-263-0/+124
| | | | Signed-off-by: Rob Clark <[email protected]>
* mesa/st: add lowering pass for YUV samplersRob Clark2016-09-263-0/+483
| | | | Signed-off-by: Rob Clark <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 22:48:03 +0000