| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
In preparation for the definition of a function to log a formatted
string.
Reviewed-by: Erik Faye-Lund <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To get equivalent information than get_vp_mode(), track the vertex
processing mode in a per context variable at
gl_vertex_program_state::_VPMode.
This aims to replace get_vp_mode() as seen in the vbo module.
But instead of the get_vp_mode() implementation which only gives correct
answers past calling _mesa_update_state() this context variable is
immediately tracked when the vertex processing state is modified. The
correctness of this value is asserted on state validation.
With this in place we should be able to untangle the dependency with
varying_vp_inputs and state invalidation.
Signed-off-by: Mathias Fröhlich <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
To reduce code duplication.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
| |
To reduce code duplication.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
| |
Cc: 17.1 <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
| |
Fixes: 00c5119a5e821 ("mesa: add KHR_no_error support for glUseProgramStages()")
Reviewed-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
| |
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
| |
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
| |
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
This will be used to create a KHR_no_error version of
glUseProgramStages().
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From Chapter 5 'Shared Objects and Multiple Contexts' of
the OpenGL 4.5 spec:
"Objects which contain references to other objects include
framebuffer, program pipeline, query, transform feedback,
and vertex array objects. Such objects are called container
objects and are not shared"
For we leave locking in place for framebuffer objects because
the EXT fbo extension allowed sharing.
We could maybe just replace the hash with an ordinary hash table
but for now this should remove most of the unnecessary locking.
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
| |
This pattern was only useful when we used mutex locks, which the previous
commit removed.
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From Chapter 5 'Shared Objects and Multiple Contexts' of
the OpenGL 4.5 spec:
"Objects which contain references to other objects include
framebuffer, program pipeline, query, transform feedback,
and vertex array objects. Such objects are called container
objects and are not shared"
For we leave locking in place for framebuffer objects because
the EXT fbo extension allowed sharing.
V2: (Timothy Arceri)
- rebased and dropped changes to framebuffer objects
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
| |
We should never get here if this is 0 unless there is a
bug. Replace the check with an assert.
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes regressions from c505d6d852220f4aaaee161465dd2c579647e672.
Switching from using gl_shader_program to gl_program for the pipline
objects CurrentProgram array meant we were freeing gl_shader_programs
immediately after glDeleteProgram was called, but the spec states
the program should only get deleted once it is no longer in use.
To work around this we add a new ReferencedPrograms array to track
gl_shader_programs in use.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
|
|
|
| |
A later patch will result in SSO programs calling this helper
per gl_program rather than per gl_shader_program.
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
|
|
|
|
|
|
| |
Now that we have a linked_stages bitfield we can use this
to check if the program is used at a later stage.
This change is also required to be able to use gl_program
rather than gl_shader_program in the CurrentProgram array.
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
| |
gl_shader_program
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case we have empty log (""), we should return 0. This fixes
Khronos WebGL conformance test 'program-infolog'.
From OpenGL ES 3.1 (and OpenGL 4.5 Core) spec:
"If pname is INFO_LOG_LENGTH , the length of the info log, including
a null terminator, is returned. If there is no info log, zero is
returned."
v2: apply same fix for get_shaderiv and _mesa_GetProgramPipelineiv (Ian)
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Iago Toral Quiroga <[email protected]> (v1)
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97321
Cc: "13.0" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One piece of ARB_shader_subroutine I ignored was the fact that it
needs to store the subroutine index data per context and not per
shader program.
There is one CTS test that tests this:
GL45-CTS.shader_subroutine.multiple_contexts
However the test only does a write to context and readback,
it never renders using the values, so this is enough to fix the
test however not enough to do what the spec says.
So with this patch the info is now stored per context, but
it gets updated into the program at UseProgram and when the
values are inserted into the context, which won't help if
multiple contexts are in use in multiple threads.
v1.1: cleanups and nit-picks (Andres)
Signed-off-by: Dave Airlie <[email protected]>
Reviewed-by: Andres Gomez <[email protected]>
|
|
|
|
|
|
| |
finally unused
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
main/pipelineobj.c: In function ‘delete_pipelineobj_cb’:
main/pipelineobj.c:110:30: warning: unused parameter ‘id’ [-Wunused-parameter]
delete_pipelineobj_cb(GLuint id, void *data, void *userData)
^
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are quite a few pipelines that desktop applications (including a
bunch of piglit test) can expect to have run but don't meet the GLES
requirements. Instead of failing validation, just emit a debug message.
Signed-off-by: Ian Romanick <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96358
Cc: "12.0" <[email protected]>
Cc: Gregory Hainaut <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
| |
v2: Move later in series to avoid issues with Gallium drivers and debug
contexts. Suggested by Ilia.
Signed-off-by: Ian Romanick <[email protected]>
Suggested-by: Timothy Arceri <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes:
GL45-CTS.shader_subroutine.subroutine_uniform_reset
Reviewed-by: Chris Forbes <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Trivial change. Removing unnecessary semi-colons from the code.
I don't have push access so someone reviewing this can push it.
Signed-off-by: Jakob Sinclair <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Edward O'Callaghan <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there is no pipe info log, we would unconditionally deref length,
which was only optionally there. _mesa_copy_string handles the source
being null, as well as the length, so may as well just always call it.
Fixes a segfault in
dEQP-GLES31.functional.state_query.program_pipeline.info_log
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Matt Turner <[email protected]>
Acked-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
|
|
|
|
| |
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_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]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enables 200+ dEQP SSO tests to proceed past validation,
and fixes a ES31-CTS.sepshaderobjs.PipelineApi subtest.
V2: split out change that reverts a previous patch into its own commit,
move variable declaration to top of function, and fix some formatting
all suggested by Ian.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
Cc: "11.1" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit ba02f7a3b6a0e4314753a8e5080db61241563f9c.
The commit checked whether the pipeline was currently bound instead
of checking whether it had ever been bound. The previous setting
of Validated during object creation makes this unnecessary. The
real problem was that Validated was not properly set to false
elsewhere in the code. This is fixed by a later patch.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
Cc: "11.1" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes following failing ES3.1 CTS tests:
ES31-CTS.sepshaderobjs.InterfacePrecisionMatchingFloat
ES31-CTS.sepshaderobjs.InterfacePrecisionMatchingInt
ES31-CTS.sepshaderobjs.InterfacePrecisionMatchingUInt
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Iago Toral Quiroga <[email protected]>
|
|
|
|
|
|
|
| |
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Marta Lofstedt <[email protected]>
[[email protected]: Reviewed-by for all except the ctx->_Shader change]
Reviewed-by: Iago Toral Quiroga <[email protected]>
|
|
|
|
|
|
|
|
| |
v2:
* Use %u for unsigned values (Iago)
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Iago Toral Quiroga <[email protected]>
|
|
|
|
| |
Reviewed-by: Tapani Pälli <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From OpenGL 4.5 Core spec (7.13):
"If pipeline is a name that has been generated (without subsequent
deletion) by GenProgramPipelines, but refers to a program pipeline
object that has not been previously bound, the GL first creates a
new state vector in the same manner as when BindProgramPipeline
creates a new program pipeline object."
I interpret this as "If GetProgramPipelineiv gets called without a
bound (but valid) pipeline object, the state should reflect initial
state of a new pipeline object." This is also expected behaviour by
ES31-CTS.sepshaderobjs.PipelineApi conformance test.
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Marta Lofstedt <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Generated by sed; no manual changes.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This was apparently missed when ARB_sso support was added.
Add label support to pipeline objects just like all the other
debug-related objects.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
Cc: "10.5 10.6" <[email protected]>
|