| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
About half of this is shareable with the VS code.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
| |
These will get virtualized as we add VS scheduling support.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
I need this so I can look at vec4 and fs registers' files from the same
.cpp file without namespaces. As far as I can tell we never rely on the
particular numerical values of the files, though I thought it sounded like
a good idea when doing the VS (it turns out having 0 be BAD_FILE is nicer).
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
This will free instruction scheduling to make better choices. No
statistically significant performance difference on GLB2.7 (n=93).
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GPU apparently goes looking for constants even though there are no
shader stages enabled, and gets stuck because we haven't told it there are
no constants to collect. If any other user of the 3D pipeline had run
(even the Render accel of the X server!) since power on, then the in-GPU
constant buffers would have been set up with some contents we didn't use,
and we would succeed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56416
Reviewed-by: Kenneth Graunke <[email protected]>
Tested-by: Dave Airlie <[email protected]>
NOTE: This is a candidate for the stable branches.
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
| |
See previous commit comments.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
| |
As with the glDraw* functions, this doesn't have to be in GLvertexformat.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove all the glDraw* functions from the GLvertexformat structure.
The point of that dispatch struct is to handle all the functions which
dispatch differently depending on whether we're inside glBegin/End.
glDraw* are never allowed inside glBegin/End so we can remove those
entries.
This simplifies the code paths and gets rid of quite a bit of code.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
| |
First step in simplifying the vertex array / glDraw dispatch code.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
| |
Just expand the code.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the currently compiled primitive state is PRIM_UNKNOWN we should
not return true from _mesa_inside_dlist_begin_end(). This lets us
simplify the calls to that function.
Note, the call to _mesa_inside_dlist_begin_end() in vbo_save_EndList()
should have probably been checking for PRIM_UNKNOWN too, but it wasn't.
So there's no code change change.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
| |
This is set during context creation/initialization. We know we're
not inside glBegin/glEnd at this point so use PRIM_OUTSIDE_BEGIN_END.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The old code didn't make sense. The clause in question did the
same thing as the next else-if clause. If we're already executing
a glBegin/End pair and we're starting a new primitive, that's an
error.
Fixes more failures in piglit gl-1.0-beginend-coverage test.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
| |
The same assignment appears later in the function.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Functions like glDrawArrays, glDrawElements, etc. are illegal between
glBegin/glEnd and should generate GL_INVALID_OPERATION.
Fixes several piglit gl-1.0-beginend-coverage failures.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The _save_OBE_DrawArrays/Elements/RangeElements() functions are
called when building a display list and we know we're outside
glBegin/End.
We shouldn't call the normal _mesa_validate_DrawArrays/Elements()
functions here because those functions only work properly in immediate
mode or during dlist execution. At dlist compile time, we can't call
_mesa_update_state(), etc. and examine the current state since it won't
apply when the list is executed later.
Fixes several failures in piglit's gl-1.0-beginend-coverage test.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
| |
If we're in GL_COMPILE_AND_EXECUTE mode and inside glBegin, calling
glEndList() should generate an error.
Fixes a failure in piglit's gl-1.0-beginend-coverage test.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
| |
The old code was hard to understand and not entirely correct.
Note that PRIM_INSIDE_UNKNOWN_PRIM is no longer set anywhere so
we'll be able to remove that next.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
| |
...in terms of new _mesa_is_valid_prim_mode(). We need a mode validater
function that doesn't depend on current state for the display list code.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
| |
Use the new PRIM_MAX value instead so that new geometry shader primitive
types are accounted for.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
| |
These values pertain to display lists, and the new types of geometry
shader primitives can be used in display lists.
And add new PRIM_MAX constant for follow-on changes.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the test for _mesa_inside_dlist_begin_end().
If ctx->Driver.CurrentSavePrimitive==PRIM_UNKNOWN (the initial value),
_mesa_inside_dlist_begin_end() will, confusingly, return TRUE.
So we didn't set the ctx->ListState.Current.ShadeModel value and it
remained in its indeterminate state.
This didn't effect correctness, but it defeated the intended optimization
of dropping redundant glShadeModel() state changes in order to
coalesce sequences of drawing commands.
Verified with new piglit gl-1.0-dlist-shademodel test.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
When checking framebuffer completeness, we test each attachment.
We verify that all attachments are consistent in terms of layers.
1. They must all be layered, or all non-layered
2. If they are layered, they must match in depth
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
If glFramebufferTexture is used, then the framebuffer attachment is
layered.
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
With glFramebufferTexture, a renderbuffer may support
all layers of the texture, so we need the depth of the
renderbuffer to check for consistency which is required
for framebuffer completeness.
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Not used anymore.
|
|
|
|
| |
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
| |
Removes the need of API_DEFINES.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
| |
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This like the fifth attempt to fix the issue.
Also with the new "validating" flag, we can set recalculate_inputs to FALSE
earlier in vbo_bind_arrays, because _mesa_update_state won't change it.
NOTE: This is a candidate for the stable branches.
v2: fixed a typo
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The shadow comparitor needs to be loaded into the Z component of the
last DWord.
Fixes es3conform's shadow_execution_vert and oglconform's
shadow-grad advanced.textureGrad.1D tests on Haswell.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the Ivybridge PRM, Volume 4 Part 1, page 130, in the
section for the sample_d message: "The r coordinate contains the faceid,
and the r gradients are ignored by hardware."
This doesn't match GLSL, which provides gradients for all of the
coordinates. So we would need to do some math to compute the face ID
before using sample_d. We currently don't have any code to do that.
However, we do have a lowering pass that converts textureGrad to
textureLod, which solves this problem. Since textureGrad on three
components is sufficiently obscure, it's not a performance path.
For now, only handle samplerCubeShadow; we need tests for samplerCube
and samplerCubeArray.
Fixes es3conform's shadow_comparison_frag test on Haswell.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
MSVC doesn't like pointer arithmetic with void * so use GLubyte *.
Reviewed-by: Jose Fonseca<[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The number of samples is already available in the miptree data
structure, so there's no need to pass it in.
I suspect this may fix a subtle bug because in one case
(intel_renderbuffer_update_wrapper) we were always passing zero for
num_samples, even though the buffer in question was not guaranteed to
be single-sampled. But I wasn't able to find a failing test case.
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The upside is less CPU overhead in fiddling with GL error handling, the
ability to use the constant color write message in most cases, and no GLSL
clear shaders appearing in MESA_GLSL=dump output. The downside is more
batch flushing and a total recompute of GL state at the end of blorp.
However, if we're ever going to use the fast color clear feature of CMS
surfaces, we'll need this anyway since it requires very special state
setup.
This increases the fail rate of some the GLES3conform ARB_sync tests,
because of the initial flush at the start of blorp. The tests already
intermittently failed (because it's just a bad testing procedure), and we
can return it to its previous fail rate by fixing the initial flush.
Improves GLB2.7 performance 0.37% +/- 0.11% (n=71/70, outlier removed).
v2: Rename the key member, use the core helper for sRGB, and use
BRW_MASK_* enums, fix comment and indentation (review by Paul).
v3: Rewrite a comment, drop a silly temporary variable (review by Ken)
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: const-qualify ctx, and add a comment about the function (recommended
by Brian and Kenneth).
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]> (v1)
|
|
|
|
|
|
|
|
|
|
| |
Improves GLB2.7 performance 0.13% +/- 0.09% (n=104/105, outliers removed).
More importantly, once color glClear()s are done through blorp in the next
commit, this reduces regression in GLES3 conformance tests that rely on
queueing up many glClear()s and having the GPU report being still busy in
an ARB_sync query after that.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
The remaining bits happen to do nothing that
_swrast_span_render_start()/finish() don't do.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
It's not really span code ever since we stopped using spans for S8.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the case of renering to windows in X, we would render to stale buffers
(or not render at all!) if you hit a MapRenderbuffer as the first thing
done to your window after new buffers are ready to be collected in DRI2.
I think this also covers the weird comment about irb->mt being missing
sometimes.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
I always forget how we do this for compressed textures.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|