summaryrefslogtreecommitdiffstats
path: root/src/mesa/main/state.c
Commit message (Collapse)AuthorAgeFilesLines
* vbo: remove vbo_context.h and change includes to use vbo.h insteadBrian Paul2018-01-241-1/+1
| | | | | | Now vbo.h is the public interface to the VBO module. Reviewed-by: Roland Scheidegger <[email protected]>
* mesa: shrink VERT_ATTRIB bitfields to 32 bitsMarek Olšák2017-11-251-1/+1
| | | | | | There are only 32 vertex attribs now. Reviewed-by: Ian Romanick <[email protected]>
* mesa: don't flag _NEW_PROGRAM_CONSTANTS for non-GLSL programs for st/mesaMarek Olšák2017-06-221-2/+12
| | | | | | | | | This has the benefit that we get to set up constants for exactly the shader stage that needs it. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: make _mesa_set_varying_vp_inputs a no-op in GL core profileMarek Olšák2017-06-221-0/+4
| | | | | | | | just don't set _NEW_VARYING_VP_INPUTS. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: don't execute most of _mesa_update_state_locked for GL core profileMarek Olšák2017-06-221-46/+58
| | | | | | | | There is plenty of legacy stuff here. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: simplify handling the return value of update_programMarek Olšák2017-06-221-3/+2
| | | | | | Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: replace VP/FP/ATIfs _Enabled flags with helper functionsMarek Olšák2017-06-221-30/+3
| | | | | | | | These are only used in the GL compatibility profile. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: don't update draw buffer bounds in _mesa_update_stateMarek Olšák2017-06-221-3/+0
| | | | | | | | | | | | | | | | st/mesa doesn't need the draw bounds for draw calls. I've added the call where it's necessary in core Mesa and drivers, but I suspect that most drivers can just move the call to the right places. The core Mesa places aren't hot paths, so the call overhead doesn't matter there. For now, only st/mesa is made such that this function is invoked very rarely. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: replace ctx->Polygon._FrontBit with a helper functionMarek Olšák2017-06-221-18/+0
| | | | | | Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: replace ctx->VertexProgram._TwoSideEnabled with a helper functionMarek Olšák2017-06-221-19/+0
| | | | | | Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: replace _mesa_update_stencil() with helper functionsMarek Olšák2017-06-221-3/+0
| | | | | | | | | | | | | The idea is to remove the dependency on _mesa_update_state_locked, so that st/mesa can skip it for stencil state updates, and then stop setting _NEW_STENCIL in mesa/main if the driver is st/mesa. The main motivation is to stop invoking _mesa_update_state_locked for certain state groups. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: inline vbo_exec_invalidate_state() and call from mesa coreTimothy Arceri2017-06-091-1/+4
| | | | | | | | Rather than calling it indirectly in each driver. Reviewed-by: Samuel Pitoiset <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: stop passing state bitfield to UpdateState()Timothy Arceri2017-06-091-5/+2
| | | | | | | | | | | | | | | | | | The code comment which seems to have been added in cab974cf6c2db (from year 2000) says: "Set ctx->NewState to zero to avoid recursion if Driver.UpdateState() has to call FLUSH_VERTICES(). (fixed?)" As far as I can tell nothing in any of the UpdateState() calls should cause it to be called recursively. V2: add a wrapper around the osmesa update function so it can still be used internally. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: remove useless check in _mesa_update_pixel()Samuel Pitoiset2017-06-071-1/+1
| | | | | | | | | The only caller is _mesa_update_state_locked() which already checks if _NEW_PIXEL is set before calling _mesa_update_pixel(). Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: remove _CurrentFragmentProgram from gl_pipeline_objectTimothy Arceri2017-05-111-8/+0
| | | | | | | | | | | | | This was added in b527dd65c830a as a work around because fixed function fragment shaders were tracked in ctx->FragmentProgram._Current as a gl_program rather than gl_shader_program. However after my refactoring of the program and shader structs at the end of 2016 which culminated in c505d6d85222, we no longer need gl_shader_program to track the current program making _CurrentFragmentProgram obsolete. Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: remove dd_function_table::BindProgramMarek Olšák2017-03-291-48/+7
| | | | | | Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: don't use _NEW_TEXTURE mainly in mesa/mainMarek Olšák2017-03-291-5/+5
| | | | | | | | v2: add missing %s Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: inline _mesa_update_textureMarek Olšák2017-03-291-2/+5
| | | | | | Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: use gl_program for CurrentProgram rather than gl_shader_programTimothy Arceri2017-01-231-31/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes much more sense and should be more performant in some critical paths such as SSO validation which is called at draw time. Previously the CurrentProgram array could have contained multiple pointers to the same struct which was confusing and we would often need to fish out the information we were really after from the gl_program anyway. Also it was error prone to depend on the _LinkedShader array for programs in current use because a failed linking attempt will lose the infomation about the current program in use which is still valid. V2: fix validate_io() to compare linked_stages rather than the consumer and producer to decide if we are looking at inward facing shader interfaces which don't need validation. Acked-by: Edward O'Callaghan <[email protected]> To avoid build regressions the following 2 patches were squashed in to this commit: mesa/meta: rewrite _mesa_shader_program_use() and _mesa_program_use() These are rewritten to do what the function name suggests, that is _mesa_shader_program_use() sets the use of all stage and _mesa_program_use() sets the use of a single stage. Reviewed-by: Lionel Landwerlin <[email protected]> Acked-by: Edward O'Callaghan <[email protected]> mesa: update active relinked program This likely fixes a subroutine bug were _mesa_shader_program_init_subroutine_defaults() would never have been called for the relinked program as we previously just set _NEW_PROGRAM as dirty and never called the _mesa_use* functions when linking. Acked-by: Edward O'Callaghan <[email protected]>
* mesa: make _CurrentFragmentProgram a gl_program struct pointerTimothy Arceri2017-01-061-12/+8
| | | | | | | | Making this point to a gl_program struct rather than a gl_shader_program struct will allow use to later also make the CurrentProgram array hold gl_program structs which in turn will allow for code simpilifcation. Reviewed-by: Eric Anholt <[email protected]>
* st/mesa/glsl/nir/i965: make use of new gl_shader_program_data in ↵Timothy Arceri2016-11-191-6/+6
| | | | | | gl_shader_program Reviewed-by: Emil Velikov <[email protected]>
* st/mesa/r200/i915/i965: move ARB program fields into a unionTimothy Arceri2016-11-171-2/+2
| | | | | | | | | | | It's common for games to compile 2000 programs or more so at 32bits x 2000 programs x 22 fields x 2 (at least) stages This should give us something like 352 kilobytes in savings once we add some more glsl only fields. Reviewed-by: Emil Velikov <[email protected]>
* st/mesa/r200/i915/i965: eliminate gl_fragment_programTimothy Arceri2016-10-261-23/+23
| | | | | | | | | | Here we move OriginUpperLeft and PixelCenterInteger into gl_program all other fields have been replace by shader_info. V2: Don't use anonymous union/structs to hold vertex/fragment fields suggested by Ian. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/mesa/st: eliminate gl_compute_programTimothy Arceri2016-10-261-5/+5
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* mesa/i965/i915/r200: eliminate gl_vertex_programTimothy Arceri2016-10-261-13/+13
| | | | | | | Here we move the only field in gl_vertex_program to the ARB program fields in gl_program. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/mesa/st: eliminate gl_geometry_programTimothy Arceri2016-10-261-5/+5
| | | | | | We now get all the gs metadata from shader_info. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/mesa/st: eliminate gl_tess_eval_programTimothy Arceri2016-10-261-6/+5
| | | | | | We now get all the tes metadata from shader_info. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/mesa/st: eliminate gl_tess_ctrl_programTimothy Arceri2016-10-261-6/+5
| | | | | | We now get all the tcs metadata from shader_info. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: optionally associate a gl_program to ATI_fragment_shaderMiklós Máté2016-03-271-1/+13
| | | | | | | | | the state tracker will use it Acked-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Miklós Máté <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* mesa: replace gl_context->Multisample._Enabled with ↵Bas Nieuwenhuizen2016-03-241-17/+0
| | | | | | | | | | | | _mesa_is_multisample_enabled. This removes any dependency on driver validation of the number of framebuffer samples. Signed-off-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Tested-by: Brian Paul <[email protected]>
* mesa: use default geometry's samples when there are no attachmentsIlia Mirkin2016-02-021-1/+1
| | | | | | | | | Whether multisampling is turned on depends, in part, on whether attachments are themselves multisample surfaces. However when there are no attachments, we should rely on the default geometry for this. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: short-cut new_state == _NEW_LINE in _mesa_update_state_locked()Brian Paul2015-10-151-1/+5
| | | | | | | | | | | We can skip to the end of _mesa_update_state_locked() if only the _NEW_LINE flag is set since none of the derived state depends on it (just like _NEW_CURRENT_ATTRIB). Note that we still call the ctx->Driver.UpdateState() function, of course. v2: use bitmask-based test, per Eric. Reviewed-by: Eric Anholt <[email protected]>
* mesa: add misc tessellation shader stuffFabian Bieler2015-07-231-4/+50
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: don't rebind constant buffers after every state change if GS is activeMarek Olšák2015-06-161-9/+3
| | | | Reviewed-by: Brian Paul <[email protected]>
* mesa: use GL_GEOMETRY_PROGRAM_NV instead of MESA_GEOMETRY_PROGRAMMarek Olšák2015-06-051-1/+1
| | | | | | | | There's no reason to use our own definition. Tessellation will use the NV definitions too. Reviewed-by: Dave Airlie <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* main: Refactor _mesa_update_draw_buffer_bounds.Laura Ekstrand2015-05-141-1/+1
| | | | | Reviewed-by: Fredrik Höglund <[email protected]> Signed-off-by: Fredrik Höglund <[email protected]>
* main: Refactor _mesa_update_framebuffer.Laura Ekstrand2015-05-141-1/+1
| | | | | | | | | _mesa_update_framebuffer now operates on arbitrary read and draw framebuffers. This allows BlitNamedFramebuffer to update the state of its arbitrary read and draw framebuffers. Reviewed-by: Fredrik Höglund <[email protected]> Signed-off-by: Fredrik Höglund <[email protected]>
* mesa/cs: Add compute support to update_program().Paul Berry2015-05-021-0/+21
| | | | | | Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* main: replace __FUNCTION__ with __func__Marius Predut2015-04-141-1/+1
| | | | | | | | | | | Consistently just use C99's __func__ everywhere. The patch was verified with Microsoft Visual studio 2013 redistributable package(RTM version number: 18.0.21005.1) Next MSVC versions intends to support __func__. No functional changes. Acked-by: Matt Turner <[email protected]> Signed-off-by: Marius Predut <[email protected]>
* mesa: Remove the _WindowMap from gl_viewport_attrib.Mathias Froehlich2015-04-051-25/+0
| | | | | | | | The _WindowMap can be dropped from gl_viewport_attrib now. Simplify gl_viewport_attrib handling where possible. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Mathias Froehlich <[email protected]>
* mesa: Use assert() instead of ASSERT wrapper.Matt Turner2015-02-231-1/+1
| | | | Acked-by: Eric Anholt <[email protected]>
* mesa: Implement ARB_clip_control.Mathias Fröhlich2014-10-241-0/+16
| | | | | | | | | | | | | | | Implement the mesa parts of ARB_clip_control. So far no driver enables this. v3: Restrict getting clip control state to the availability of ARB_clip_control. Move to transformation state. Handle clip control state with the GL_TRANSFORM_BIT. Move _FrontBit update into state.c. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Mathias Froehlich <[email protected]>
* mesa: Refactor viewport transform computation.Mathias Fröhlich2014-10-241-4/+5
| | | | | | | | | | This is for preparation of ARB_clip_control. v3: Add comments. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Mathias Froehlich <[email protected]>
* mesa: Delete VAO _MaxElement code and index buffer bounds checking.Kenneth Graunke2014-09-191-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fredrik's implementation of ARB_vertex_attrib_binding introduced new gl_vertex_attrib_array and gl_vertex_buffer_binding structures, and converted Mesa's older gl_client_array to be derived state. Ultimately, we'd like to drop gl_client_array and use those structures directly. One hitch is that gl_client_array::_MaxElement doesn't correspond to either structure (unlike every other field), so we'd have to figure out where to store it. The _MaxElement computation uses values from both structures, so it doesn't really belong in either place. We could put it in the VAO, but we'd have to pass it around everywhere. It turns out that it's only used when ctx->Const.CheckArrayBounds is set, which is only set by the (rarely used) classic swrast driver. It appears that drivers/x11 used to set it as well, which was intended to avoid segmentation faults on out-of-bounds memory access in the X server (probably for indirect GLX clients). However, ajax deleted that code in 2010 (commit 1ccef926be46dce3b6b5c76e812e2fae4e205ce7). The bounds checking apparently doesn't actually work, either. Non-VBO attributes arbitrarily set _MaxElement to 2 * 1000 * 1000 * 1000. vbo_save_draw and vbo_exec_draw remark /* ??? */ when setting it, and the i965 code contains a comment noting that _MaxElement is often bogus. Given that the code is complex, rarely used, and dubiously functional, it doesn't seem worth maintaining going forward. This patch drops it. This will probably mean the classic swrast driver may begin crashing on out of bounds vertex buffer access in some cases, but I believe that is allowed by OpenGL (and probably happened for non-VBO accesses anyway). There do not appear to be any Piglit regressions, either. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Acked-by: Roland Scheidegger <[email protected]>
* mesa/sso: rename Shader to the pointer _ShaderGregory Hainaut2014-03-251-7/+7
| | | | | | | | | | | | | | | | Basically a sed but shaderapi.c and get.c. get.c => GL_CURRENT_PROGAM always refer to the "old" UseProgram behavior shaderapi.c => the old api stil update the Shader object directly V2: formatting improvement V3 (idr): * Rebase fixes after a block of code was moved from ir_to_mesa.cpp to shaderapi.c. * Trivial reformatting. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Rename _mesa_..._array_obj functions to _mesa_..._vao.Kenneth Graunke2014-02-031-2/+2
| | | | | | | | | | | | | | | _mesa_update_vao_client_arrays() is less of a mouthful than _mesa_update_array_object_client_arrays(), and generally clearer. Generated by: $ find . -type f -print0 | xargs -0 sed -i \ 's/_mesa_\([^_]*\)_array_object/_mesa_\1_vao/g' with manual whitespace and indentation fixes applied. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Rename ArrayObj to VAO and DefaultArrayObj to DefaultVAO.Kenneth Graunke2014-02-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When reading through the Mesa drawing code, it's not immediately obvious to me that "ArrayObj" (gl_array_object) is the Vertex Array Object (VAO) state. The comment above the structure explains this, but readers still have to remember this and translate accordingly. Out of context, "array object" is a fairly vague. Even in context, "array" has a lot of meanings: glDrawArrays, vertex data stored in user arrays, gl_client_arrays, gl_vertex_attrib_arrays, and so on. Using the term "VAO" immediately associates these fields with the OpenGL concept, clarifying the situation and aiding programmer sanity. Completely generated by: $ find . -type f -print0 | xargs -0 sed -i \ -e 's/ArrayObj;/VAO;/g' \ -e 's/->ArrayObj/->VAO/g' \ -e 's/Array\.ArrayObj/Array.VAO/g' \ -e 's/Array\.DefaultArrayObj/Array.DefaultVAO/g' v2: Rerun command to resolve conflicts with Ian's meta patches. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Fold long lines introduced by the previous patch.Paul Berry2014-01-211-3/+6
| | | | | Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Replace ctx->Shader.Current{Vertex,Fragment,Geometry}Program with an ↵Paul Berry2014-01-211-4/+4
| | | | | | | | | | | | | | | | | | | | | array. These are replaced with ctx->Shader.CurrentProgram[MESA_SHADER_{VERTEX,FRAGMENT,GEOMETRY}]. In patches to follow, this will allow us to replace a lot of ad-hoc logic with a variable index into the array. With the exception of the changes to mtypes.h, this patch was generated entirely by the command: find src -type f '(' -iname '*.c' -o -iname '*.cpp' ')' \ -print0 | xargs -0 sed -i \ -e 's/\.CurrentVertexProgram/.CurrentProgram[MESA_SHADER_VERTEX]/g' \ -e 's/\.CurrentGeometryProgram/.CurrentProgram[MESA_SHADER_GEOMETRY]/g' \ -e 's/\.CurrentFragmentProgram/.CurrentProgram[MESA_SHADER_FRAGMENT]/g' Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Initialize all the viewportsIan Romanick2014-01-201-5/+8
| | | | | | | | | | | | | v2: Use MAX_VIEWPORTS instead of ctx->Const.MaxViewports because the driver may not set ctx->Const.MaxViewports yet. v3: Handle all viewport entries in update_viewport_matrix and _mesa_copy_context too. This was previously in an earlier patch. Having the code in the earlier patch could cause _mesa_copy_context to access a matrix that hadn't been constructed. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> [v2]