| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Remove some unused or unused but set variables
from the vbo module.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is necessary because i965 will need to call vbo_bind_array() when
cleaning up after a buffer resolve meta-op.
Detailed Explanation
--------------------
The vbo module tracks vertex attributes separately from the gl_context.
Specifically, the vbo module maintins vertex attributes in
vbo_exec_context::array::inputs, which is synchronized with
gl_context::Array::ArrayObj::VertexAttrib by vbo_bind_array().
vbo_draw_arrays() calls vbo_bind_array() to perform the synchronization
before calling the real draw call, vbo_context::draw_arrays.
Intel hardware accomplishes buffer resolves with a meta-op. Frequently,
that meta-op must be performed within glDraw* in the moment immediately
before the draw occurs (The hardware designers hate us...). After
performing the meta-op, but before calling vbo_bind_array(), the
gl_context's vertex attributes will have been restored to their original
state (that is, their state before the meta-op began), but the vbo
module's vertex attribute are those used in the last meta-op. Therefore we
must manually synchronize the two with vbo_bind_array() before continuing
with the original draw command (that is, the one requested with glDraw*).
See brw_predraw_resolve_buffers(), which will be added in a future commit.
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This hook allows the driver to prepare for a glBegin/glEnd.
i965 will use the hook to avoid avoid recursive calls to FLUSH_VERTICES
during a buffer resolve meta-op.
Detailed Justification
----------------------
When vertices are queued during a glBegin/glEnd block, those vertices must
of course be drawn before any rendering state changes. To enusure this,
Mesa calls FLUSH_VERTICES as a prehook to such state changes. Therefore,
FLUSH_VERTICES itself cannot change rendering state without falling into
a recursive trap.
This precludes meta-ops, namely i965 buffer resolves, from occuring while
any vertices are queued. To avoid that situation, i965 must satisfy the
following condition: that it queues no vertex if a buffer needs resolving.
To satisfy this, i965 will use the PrepareExecBegin hook to resolve all
buffers on entering a glBegin/glEnd block.
--------
v2: Don't add dd_function_table::CleanupExecEnd. Anholt and I discovered
that hook to be unnecessary.
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is supported by the pseudo-code on pages 27 and 28 (pages 41 and
42 of the PDF) of the OpenGL 2.1 spec. The last part of the
implementation of ArrayElement is:
if (generic attribute array 0 enabled) {
if (generic vertex attribute 0 array normalization flag is set, and
type is not FLOAT or DOUBLE)
VertexAttrib[size]N[type]v(0, generic vertex attribute 0 array element i);
else
VertexAttrib[size][type]v(0, generic vertex attribute 0 array element i);
} else if (vertex array enabled) {
Vertex[size][type]v(vertex array element i);
}
Page 23 (page 37 of the PDF) of the same spec says:
"Setting generic vertex attribute zero specifies a vertex; the
four vertex coordinates are taken from the values of attribute
zero. A Vertex2, Vertex3, or Vertex4 command is completely
equivalent to the corresponding VertexAttrib* command with an
index of zero."
Fixes piglit test attribute0.
NOTE: This is a candidate for stable branches.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d631c19db47181129811080bfa772b210d762d4d.
The commit was broken, and ended up returning false all the time
because nobody in the world binds every single possible vertex array.
On further reflection, we don't want to discount stride == 0: This
function is just used for deciding to calculate whether to compute the
bonuds on the index, and there's no sense in computing index bounds
when stride == 0.
For the separate question of "how much data do I upload for this
vertex element?", the i965 driver was fixed to upload the data.
Fixes a regression of about 2x in 3DMMES, and most importantly, makes
Hammerfight playable.
|
|
|
|
|
|
|
| |
INLINE is still seen in some files (some generated files, etc) but this
is a good start.
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
We now raise an GL_INVALID_ENUM in glBegin() if mode is illegal, as was
done in Yuanhan Liu's original patch.
Take geometry shaders support into account too.
Reviewed-by: Yuanhan Liu <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trigger GL_INVALID_ENUM error if the face paramter is not a valid value.
Trigger GL_INVALID_VALUE error if the GL_SHININESS value is out side
[0, ctx->Constant.MaxShiniess].
v2: fix the max shininess value.
v3: suggested by Brian, move the face check into glMaterialfv function
to reduce code duplicate. Also, refactor the error message.
Signed-off-by: Yuanhan Liu <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
| |
MSVC does not support inline keyword.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the vertex processing paths for the 2101010 types. It converts
the attributes to floats for all the immediate entry points, some entrypoints
are normalised and the attrib APIs take a normalized parameter.
There are four main paths,
ui10 -> float unnormalized
i10 -> float unnormalized
ui10 -> float normalized
i10 -> float normalized
along with the ui2/i2 equivs.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Acked-by: Kristian Høgsberg <[email protected]>
Acked-by: Marek Olšák <[email protected]>
Acked-by: Alan Coopersmith <[email protected]>
Acked-by: Jakob Bornecrantz <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Build-Tested-by: Jakob Bornecrantz <[email protected]>
Tested-by: Eugeni Dodonov <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Replace all calls to dd_function_table::MapBuffer with appropriate
calls to dd_function_table::MapBufferRange, then remove all the cruft.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
No driver used that parameter, and most drivers ended up with a bunch
of unused-parameter warnings because it was there.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
No driver used that parameter, and most drivers ended up with a bunch
of unused-parameter warnings because it was there.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
No driver used that parameter, and most drivers ended up with a bunch
of unused-parameter warnings because it was there.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
No driver used that parameter, and most drivers ended up with a bunch
of unused-parameter warnings because it was there.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
No driver used that parameter, and most drivers ended up with a bunch
of unused-parameter warnings because it was there.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
Move vbo_exec_FlushVertices_internal out of FEATURE_beginend.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
| |
That code drops performance in Unigine Heaven and Tropics
by a factor of 10. That's too crazy even for a debug build.
NOTE: This is a candidate for the 7.11 branch.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
this moves getting the context into the debug in this function,
just spotted it trawling callgrind traces for other things.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In fixed function, stride == 0 (e.g. glColor4f() outside of the draw
call) would get turned into uniform inputs, which is why it was
ignored originally in this test. For shaders, drivers end up seeing a
need to upload stride == 0 data, and get confused by needing to upload
when vbo_all_varyings_in_vbos() returned true. In the 965 driver
case, it wouldn't bother to compute the min/max index, and uploaded
nothing if the min/max wasn't known.
We've talked about removing the ff stride=0-into-uniforms code, so
this check shouldn't be missed once that's gone.
Fixes ARB_vertex_buffer_object/mixed-immediate-and-vbo
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37934
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
We would still want to consider that data as being in a VBO even if we
managed to produce this case, which as far as I know we can't.
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See piglit dlist-fdo31590.c test and
http://bugs.freedesktop.org/show_bug.cgi?id=31590
In this case we had node->prim_count=1 but node->count==0 because the
display list started with glBegin() but had no vertices. The call to
glEvalCoord1f() triggered the DO_FALLBACK() path. When replaying the
display list, the old condition basically no-op'd the call to
vbo_save_playback_vertex_list call(). That led to the invalid operation
error being raised in glEnd().
NOTE: This is a candidate for the 7.10 branch.
|
|
|
|
|
|
| |
See the piglit dlist-fdo31590.c test
NOTE: This is a candidate for the 7.10 branch.
|
| |
|
|
|
|
| |
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
| |
This fixes a Coverity warning about uninitialized data.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
We adjust 'end' to fit into _MaxElement, but that may result into a 'start'
value bigger than 'end' being passed downstream, causing havoc.
This could be seen with arb_robustness_draw-vbo-bounds, due to an
application bug.
|
|
|
|
|
| |
This fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=34378
|
|
|
|
| |
Spotted by Ian.
|
|
|
|
|
|
| |
Drivers can call this function as needed. It tells the VBO module to
always unmap the current glBegin/glEnd VBO when we flush. Otherwise
it's possible to be in a flushed state but still have the VBO mapped.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|