summaryrefslogtreecommitdiffstats
path: root/src/mesa/main
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Fix warning with MESA_VERBOSE=api for BindBufferRangeJordan Justen2016-01-011-1/+1
| | | | | Reported-by: Dieter Nützel <[email protected]> Signed-off-by: Jordan Justen <[email protected]>
* mesa: Add MESA_VERBOSE=api for GL_ARB_program_interface_queryJordan Justen2016-01-011-0/+39
| | | | | | | | | v2: * Add braces '{}' when the _mesa_debug call spans multiple lines (Ken) Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Add MESA_VERBOSE=api for several indexed BindBuffer variantsJordan Justen2016-01-011-2/+25
| | | | | | | | v2: * Add braces '{}' when the _mesa_debug call spans multiple lines (Ken) Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* mesa: Add core mesa support for GL_ARB_shader_draw_parametersKristian Høgsberg Kristensen2015-12-292-0/+2
| | | | Reviewed-by: Anuj Phogat <[email protected]>
* mesa: fix interface matching done in validate_ioTapani Pälli2015-12-221-27/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch makes following changes for interface matching: - do not try to match builtin variables - handle swizzle in input name, as example 'a.z' should match with 'a' - add matching by location - check that amount of inputs and outputs matches These changes make interface matching tests to work in: ES31-CTS.sepshaderobjs.StateInteraction The test still does not pass completely due to errors in rendering output. IMO this is unrelated to interface matching. Note that type matching is not done due to varying packing which changes type of variable, this can be added later on. Preferably when we have quicker way to iterate resources and have a complete list of all existed varyings (before packing) available. v2: add spec reference, return true on desktop since we do not have failing cases for it, inputs and outputs amount do not need to match on desktop. v3: add some more spec reference, remove desktop specifics since not used for now on desktop, add match by location qualifier, rename input_stage and output_stage as producer and consumer as suggested by Timothy. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: add SSBOs to the list of fragment shader side effectsIago Toral Quiroga2015-12-221-1/+3
| | | | | | | | | | | | | | | | | | | The i965 driver uses this function to decide if it can disable the FS unit in the absence of color/depth writes. We don't want to disable the unit in the presence of SSBOs, since the fragment shader could be writing to it. We could go a step further and check not just for the presence of SSBOs but also if the shader code writes to them. Does not look worth the trouble though and we are not doing this for atomic buffers either anyway. v2: put this into a generic _mesa_active_fragment_shader_has_side_effects function instead of having one specific for SSBOs (Jason). Fixes the following CTS test: ES31-CTS.shader_storage_buffer_object.advanced-usage-sync-vsfs Reviewed-by: Francisco Jerez <[email protected]>
* mesa: Add a _mesa_active_fragment_shader_has_side_effects helperIago Toral Quiroga2015-12-221-3/+12
| | | | | | | | | | | | | | | Some drivers can disable the FS unit if there is nothing in the shader code that writes to an output (i.e. color, depth, etc). Right now, mesa has a function to check for atomic buffers and the i965 driver also checks for images. Refactor this logic into a generic function that we can use for any source of side effects in a fragment shader. Suggested by Jason. v2: - Use '_Shader', as suggested by Tapani, to fix the following CTS test: ES31-CTS.shader_atomic_counters.advanced-usage-many-draw-calls2 Reviewed-by: Francisco Jerez <[email protected]>
* swrast: move two global defines to the only place where they are usedMiklós Máté2015-12-171-2/+0
| | | | Reviewed-by: Ian Romanick <[email protected]>
* mesa: improve debug log in atifragshaderMiklós Máté2015-12-171-0/+3
| | | | Reviewed-by: Ian Romanick <[email protected]>
* mesa: Don't leak ATIfs instructions in DeleteFragmentShaderMiklós Máté2015-12-171-1/+1
| | | | | Reviewed-by: Ian Romanick <[email protected]> Cc: "11.0 11.1" <[email protected]>
* main/version: Don't require ARB_compute_shader for OpenGLES 3.1Jordan Justen2015-12-161-3/+6
| | | | | | | | | The OpenGL ARB_compute_shader extension specfication requires at least 1024 for GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS, whereas OpenGLES 3.1 only required 128. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* main: Allow compute shaders to be compiled with OpenGLES 3.1Jordan Justen2015-12-161-1/+1
| | | | | | | | | Previous OpenGLES 3.1 testing had been done when ARB_compute_shader was overridden to enabled. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Reviewed-by: Marta Lofstedt <[email protected]>
* main: Add MESA_VERBOSE=api for LinkProgram & UseProgramJordan Justen2015-12-161-0/+5
| | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa/blit: Don't require the same format for mulitisample blitsNeil Roberts2015-12-161-2/+11
| | | | | | | | | | | | | | | | | | | | | | | Previously the GL spec required that whenever glBlitFramebuffer is used with either buffer being multisampled, the internal formats must match. However the GL 4.4 spec was later changed to remove this restriction. In the section entitled “Changes in the released Specification of July 22, 2013” it says: “Relax BlitFramebuffer in section 18.3.1 so that format conversion can take place during multisample blits, since drivers already allow this and some apps depend on it.” If most drivers already allowed this in earlier versions I think it's safe to assume that this is a spec bug and it should also be allowed in all versions. This patch just removes the restriction on desktop GL. For GLES there are conformance tests that assert the previous behaviour so it is probably safer to leave it in. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92706 Reviewed-by: Ian Romanick <[email protected]>
* mesa/main: use BITSET_FOREACH_SET in perf_monitor_result_sizeNicolai Hähnle2015-12-151-4/+3
| | | | | | | This should make the code both faster and slightly clearer. Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* mesa/shader: return correct attribute location for double matrix arraysDave Airlie2015-12-111-3/+8
| | | | | | | | | | | | | | | | | | | If we have a dmat2[4], then dmat2[0] is at 17, dmat2[1] at 19, dmat2[2] at 21 etc. The old code was returning 17,18,19. I think this code is also wrong for float matricies as well. There is now a piglit for the float case. This partly fixes: GL41-CTS.vertex_attrib_64bit.limits_test [airlied: update with Tapani suggestion to clean it up]. Cc: "11.0 11.1" <[email protected]> Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* blit: Don't take into account the Mesa format when checking MSRT blitNeil Roberts2015-12-101-13/+15
| | | | | | | | | | | | | | | | | | | | | | According to the GLES3 spec, blitting between multisample FBOs with different internal formats should not be allowed. The compatible_resolve_formats function implements this check. Previously it had a shortcut where if the Mesa formats of the two renderbuffers were the same then it would assume the blit is ok. However some drivers map different internal formats to the same Mesa format, for example it might implement both GL_RGB and GL_RGBA textures with MESA_FORMAT_R8G8B8A_UNORM. The function is used to generate a GL error according to what the GL spec requires so the blit should not be allowed in that case. This patch just removes the shortcut so that it only ever looks at the internal format. Note that I posted a related patch to disable this check altogether for desktop GL. However this function is still used on GLES3 because there are conformance tests that require this behaviour so this patch is still useful. Cc: Marek Olšák <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* glsl: Add lowering pass for shared variable referencesJordan Justen2015-12-091-0/+7
| | | | | | | | | | | | | | | | | In this lowering pass, shared variables are decomposed into intrinsic calls. v2: * Send mem_ctx as a parameter (Iago) v3: * Shared variables don't have an associated interface block (Iago) * Always use 430 packing (Iago) * Comment / whitespace cleanup (Iago) Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* mesa: invalidate pipeline status after glUseProgramStagesTapani Pälli2015-12-101-0/+2
| | | | | | | | | | | | This will cause validation to run during next draw, this is done because possible changes in used stages and programs can cause invalid pipeline state. This fixes a subtest in following CTS test: ES31-CTS.sepshaderobjs.StateInteraction Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa/varray: set double arrays to non-normalised.Dave Airlie2015-12-101-1/+1
| | | | | | | | | | | Doesn't have any effect in practice I don't think, but CTS reads back using GetVertexAttrib. This fixes: GL41-CTS.vertex_attrib_64bit.get_vertex_attrib Cc: "11.0 11.1" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* mesa: fix ID usage for buffer warningsBrian Paul2015-12-091-6/+12
| | | | | | We need a different ID pointer for each call site. Reviewed-by: Ilia Mirkin <[email protected]>
* mesa: Fix a typo in a commentAndreas Boll2015-12-091-1/+1
| | | | | | | s/suports/supports/ Signed-off-by: Andreas Boll <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Fix typos in print messagesAndreas Boll2015-12-092-2/+2
| | | | | | | | s/inconsistant/inconsistent/ s/occurences/occurrences/ Signed-off-by: Andreas Boll <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: detect inefficient buffer use and report through debug outputBrian Paul2015-12-092-0/+59
| | | | | | | | | | | | | | | When a buffer is created with GL_STATIC_DRAW, its contents should not be changed frequently. But that's exactly what one application I'm debugging does. This patch adds code to try to detect inefficient buffer use in a couple places. The GL_ARB_debug_output mechanism is used to report the issue. NVIDIA's driver detects these sort of things too. Other types of inefficient buffer use could also be detected in the future. Reviewed-by: José Fonseca <[email protected]>
* mesa: remove _mesa_tex_target_is_arrayAlejandro Piñeiro2015-12-072-17/+0
| | | | | | | | | | | | _mesa_is_array_texture provides the same functionality and: 1. it returns bool instead of GLboolean 2. it's not related to the texture format (texformat.c) 3. the name's a little shorter v2: remove _mesa_tex_target_is_array instead (Brian Paul) Reviewed-by: Brian Paul <[email protected]>
* mesa: move GLES checks for SSO input/output validationTimothy Arceri2015-12-071-22/+23
| | | | | | | | | This function is unfinished there is a bunch more validation rules that need to be applied here. We will still want to call it for desktop GL we just don't want to validate precision so move the ES check to reflect this. Reviewed-by: Tapani Pälli <[email protected]>
* mesa: move GL_INVALID_OPERATION error to rendering callTimothy Arceri2015-12-073-25/+15
| | | | | | | | The validation api doesn't trigger this error so just move it to the code called during rendering. Reviewed-by: Tapani Pälli <[email protected]> Cc: Kenneth Graunke <[email protected]>
* mesa: move pipeline input/output validation inside ↵Timothy Arceri2015-12-071-15/+15
| | | | | | | | | | | | _mesa_validate_program_pipeline() This allows validation to be done on rendering calls also. Fixes 3 dEQP-GLES31.functional.separate tests. Cc: "11.1" <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Cc: Kenneth Graunke <[email protected]>
* glsl: re-validate program pipeline after sampler changeTimothy Arceri2015-12-071-0/+4
| | | | | | | Cc: "11.1" <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Cc: Kenneth Graunke <[email protected]> https://bugs.freedesktop.org/show_bug.cgi?id=93180
* mesa/tests: add KHR_debug GLES glGetPointervKHR entry pointsEmil Velikov2015-12-041-1/+4
| | | | | | | | | | | | | | Should have been part of commit f53f9eb8d49 "glapi: add GetPointervKHR to the ES dispatch". v2: comment out the ES1.1 symbol and use the same description (pattern) as elsewhere (Matt) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93235 Fixes: f53f9eb8d49 "glapi: add GetPointervKHR to the ES dispatch". Signed-off-by: Emil Velikov <[email protected]> Tested-by: Vinson Lee <[email protected]> (v1) Tested-by: Michel Dänzer <[email protected]>
* mesa: rework the meaning of gl_debug_message::lengthEmil Velikov2015-12-031-16/+24
| | | | | | | | | | | | | | | | | | | Currently it stores strlen(buf) whenever the user originally provided a negative value for length. Although I've not seen any explicit text in the spec, CTS requires that the very same length (be that negative value or not) is returned back on Pop. So let's push down the length < 0 checks, tweak the meaning of gl_debug_message::length and fix GetDebugMessageLog to add and count the null terminators, as required by the spec. v2: return correct total length in GetDebugMessageLog v3: rebase (drop _mesa_shader_debug hunk). Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: errors: validate the length of null terminated stringEmil Velikov2015-12-031-3/+17
| | | | | | | | | We're about to rework the meaning of gl_debug_message::length to only store the user provided data. Thus we should add an explicit validation for null terminated strings. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: accept TYPE_PUSH/POP_GROUP with glDebugMessageInsertEmil Velikov2015-12-031-1/+1
| | | | | | | | | | | | | | | | | | These new (relative to ARB_debug_output) tokens, have been explicitly separated from the existing ones in the spec text. With the reference to glDebugMessageInsert was dropped. At the same time, further down the spec says: "The value of <type> must be one of the values from Table 5.4" ... and these two are listed in Table 5.4. The GL 4.3 and GLES 3.2 do not give any hints on the former 'definition', plus CTS requires that the tokens are valid values for glDebugMessageInsert. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: add SEVERITY_NOTIFICATION to default stateEmil Velikov2015-12-031-2/+3
| | | | | | | | | | | | As per the spec quote: "All messages are initially enabled unless their assigned severity is DEBUG_SEVERITY_LOW" We already had MEDIUM and HIGH set, let's toggle NOTIFICATION as well. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: return the correct value for GroupStackDepthEmil Velikov2015-12-031-1/+1
| | | | | | | | We already have one group (the default) as specified in the spec. So lets return its size, rather than the index of the current group. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: rename GroupStackDepth to CurrentGroupEmil Velikov2015-12-031-16/+16
| | | | | | | | | The variable is used as the actual index, rather than the size of the group stack - rename it to reflect that. Suggested-by: Ilia Mirkin <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: do not enable KHR_debug for ES 1.0Emil Velikov2015-12-031-1/+1
| | | | | | | | | | | | The extension requires (cough implements) GetPointervKHR (alias of GetPointerv) which in itself is available for ES 1.1 enabled mesa. Anyone willing to fish around and implement it for ES 1.0 is more than welcome to revert this commit. Until then lets restrict things. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93048 Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa/version: Update gl_extensions::Version during version overrideNanley Chery2015-12-031-0/+1
| | | | | | | | | | | Commit a16ffb743ced9fde80b2485dfc2d86ae74e86f25, which introduced gl_extensions::Version, updates the field when the context version is computed and when entering/exiting meta. Update this field when the version is overridden as well. Cc: "11.1" <[email protected]> Signed-off-by: Nanley Chery <[email protected]> Reviewed-by: Marta Lofstedt <[email protected]>
* mesa: print enum names rather than hexadecimal values in error messagesBrian Paul2015-12-031-6/+6
| | | | Trivial.
* mesa: print enum string in compressed_subtexture_error_check() error msgBrian Paul2015-12-021-2/+2
| | | | Trivial.
* mesa: fix VIEWPORT_INDEX_PROVOKING_VERTEX and LAYER_PROVOKING_VERTEX queriesRoland Scheidegger2015-12-023-2/+8
| | | | | | | | | | | | | These are implementation-dependent queries, but so far we just returned the value of whatever the current provoking vertex convention was set to, which was clearly wrong. Just make this a variable in the context constants like for other things which are implementation dependent (I assume all drivers will want to set this to the same value for both queries), and set it to GL_UNDEFINED_VERTEX which is correct for everybody (and drivers can override it). Reviewed-by: Brian Paul <[email protected]> CC: <[email protected]>
* Remove Sun CC specific code.Jose Fonseca2015-12-021-14/+0
| | | | | Reviewed-by: Matt Turner <[email protected]> Acked-by: Alan Coopersmith <[email protected]>
* mesa: Drop the blacklisting of new GL enums.Eric Anholt2015-12-011-3/+2
| | | | | | | | | | | | | Now when people need new extensions, they can skip the entire enum-definition process, and we can stop reviewing new extension XML for its enum content. This also brings in a new enum that I wanted to use in enum_strings.cpp for testing the code generator. v2: Drop comment about disabled GL_1PASS_EXT test. Reviewed-by: Ian Romanick <[email protected]>
* mesa: Drop bitfield "enums" from the enum-to-string table.Eric Anholt2015-12-011-13/+12
| | | | | | | | | | | | | | Asking the table for bitfield names doesn't make any sense. For 0x10, do you want GL_GLYPH_HORIZONTAL_BEARING_ADVANCE_BIT_NV or GL_COLOR_BUFFER_BIT4_QCOM or GL_POLYGON_STIPPLE_BIT or GL_SHADER_GLOBAL_ACCESS_BARRIER_BIT_NV? Giving a useful answer would depend on a whole lot of context. This also fixes a bad enum table entry, where we chose GL_HINT_BIT instead of GL_ABGR_EXT for 0x8000, so we can now fix its entry in the enum_strings test. Reviewed-by: Ian Romanick <[email protected]>
* mesa: Drop apparently typoed GL_ALL_CLIENT_ATTRIB_BITS.Eric Anholt2015-12-011-3/+1
| | | | | | | | GL_ALL_ATTRIB_BITS is a thing, and GL_CLIENT_ALL_ATTRIB_BITS, but I don't see GL_ALL_CLIENT_ATTRIB_BITS in my grepping of khronos XML, GL extension specs, GL 1.1, GL 2.2, and GL 4.4. Reviewed-by: Brian Paul <[email protected]>
* mesa: Cut enum_strings.cpp test down to a few hand-chosen enums.Eric Anholt2015-12-011-1822/+36
| | | | | | | | | | | | | | | | The previous contents appeared to be the output of some form of code generation for all enums, with a few entries hand-edited to deal with oddness. The downside to this was that when an enum gets promoted from vendor to _EXT or _EXT to _ARB or _ARB to core, make check starts failing even when the commiter has done nothing wrong. Instead of black-box testing the code generation, pick a few enums that intentionally poke the interesting cases of code generation. People editing the code generator should be diffing the generated code anyway. This should catch when they fail to do so, without throwing false negatives when people update the GL XML. Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove len argument from _mesa_shader_debug()Emil Velikov2015-11-292-7/+6
| | | | | | | | | | There was only a single user which was using strlen(buf). As this function is not user facing (i.e. we don't need to feed back original length via a callback), we can simplify things. Suggested-by: Timothy Arceri <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: support GL_RED/GL_RG in ES2 contexts when driver support existsIlia Mirkin2015-11-284-4/+11
| | | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93126 Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]> Cc: "11.0 11.1" <[email protected]>
* glsl: don't generate extra errors in ValidateProgramPipelineTimothy Arceri2015-11-271-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | From Section 11.1.3.11 (Validation) of the GLES 3.1 spec: "An INVALID_OPERATION error is generated by any command that trans- fers vertices to the GL or launches compute work if the current set of active program objects cannot be executed, for reasons including:" It then goes on to list the rules we validate in the _mesa_validate_program_pipeline() function. For ValidateProgramPipeline the only mention of generating an error is: "An INVALID_OPERATION error is generated if pipeline is not a name re- turned from a previous call to GenProgramPipelines or if such a name has since been deleted by DeleteProgramPipelines," Which we handle separately. This fixes: ES31-CTS.sepshaderobjs.PipelineApi No regressions on the eEQP 3.1 tests. Cc: Gregory Hainaut <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa: remove ARB_geometry_shader4Marta Lofstedt2015-11-268-82/+8
| | | | | | | | | | No drivers currently implement ARB_geometry_shader4, nor are there any plans to implement it. We only support the version of geometry shaders that was incorporated into OpenGL 3.2 / GLSL 1.50. Signed-off-by: Marta Lofstedt <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 03:15:23 +0000