| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
This extension is identical to ARB_base_instance. Reuse the same
entrypoints.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When applications stream their index buffers, the caches for those BOs become
useless and add overhead, so we want to disable them. The tricky part is
coming up with the right heuristic for *when* to disable them.
The first question is which hit rate to aim for. Since I'm not aware of any
interesting borderline applications that do something like "draw two or three
times for each upload", I just kept it simple.
The second question is how soon we should give up on the caching. Applications
might have a warm-up phase where they fill a buffer gradually but then keep
reusing it. For this reason, I count the number of indices that hit and miss
(instead of the number of calls that hit or miss), since comparing that to
the size of the buffer makes sense.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some games developers are unaware that an index buffer in a VBO still needs
to be read by the CPU if some varying data comes from a user pointer (unless
glDrawRangeElements and friends are used). This is particularly bad when
they tell us that the index buffer should live in VRAM.
This cache helps, e.g. lifting This War Of Mine (a particularly bad
offender) from under 10fps to slightly over 20fps on a Carrizo.
Note that there is nothing prohibiting a user from rendering from multiple
threads simultaneously with the same index buffer, hence the locking. (The
internal buffer map taken for the buffer still leads to a race, but at least
the locks are a move in the right direction.)
v2: disable the cache on USAGE_TEXTURE_BUFFER as well (Chris Forbes)
v3:
- use bool instead of GLboolean for MinMaxCacheDirty (Ian Romanick)
- replace the sticky USAGE_PERSISTENT_WRITE_MAP bit by a direct
AccessFlags check
Reviewed-by: Chris Forbes <[email protected]> (v2)
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
We will add more code for caching/memoization. Moving the existing code
into its own file helps keep things modular.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All indirect draws are passed to the new draw function. By default
there's a fallback implementation which pipes it right back to
draw_prims, but eventually both the fallback and draw_prim's support for
indirect drawing should be removed.
This should allow a backend to properly support ARB_multi_draw_indirect
and ARB_indirect_parameters.
Signed-off-by: Ilia Mirkin <[email protected]>
Acked-by: Marek Olšák <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
The drivers will need this for passing in gl_DrawIDARB. For indirect
multidraw calls, we get the prim array and prim[i].draw_id == i and is
redundant. But for non-indirect calls, we get one primitive at a time
and need the draw_id field.
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Very long line loops which spanned 3 or more vertex buffers were not
handled correctly and could result in stray lines.
The piglit lineloop test draws 10000 vertices by default, and is not
long enough to trigger this. Even 'lineloop -count 100000' doesn't
trigger the bug.
For future reference, the issue can be reproduced by changing Mesa's
VBO_VERT_BUFFER_SIZE to 4096 and changing the piglit lineloop test to
use glVertex2f(), draw 3 loops instead of 1, and specifying -count
1023.
Acked-by: Sinclair Yeh <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
| |
This has been tested with the piglits in the mailing list and
on the Dolphin emulator.
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
|
| |
With just the right sequence of per-vertex commands and state changes,
it's possible for this assertion to fail (such as with viewperf11's
lightwave-06-1 test). Instead of asserting, return 0 so that the
caller knows the VBO is full and needs to be flushed.
Reviewed-by: Charmaine Lee <[email protected]>
|
|
|
|
|
|
|
| |
Instead of calling memcpy() 'n' times, we can do it all at once since
the source and dest regions are all contiguous.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a long GL_LINE_LOOP prim was split across primitives we drew
stray lines. See previous commit for details.
This patch converts GL_LINE_LOOP prims into GL_LINE_STRIP prims so
that drivers don't have to worry about the _mesa_prim::begin/end flags.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81174
Reviewed-by: Jose Fonseca <[email protected]>
Acked-by: Sinclair Yeh <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When long GL_LINE_LOOP primitives don't fit in one vertex buffer they
have to be split across buffers. The code to do this was basically correct
but drivers had to pay special attention to the _mesa_prim::begin,end flags
in order to draw the sections of the line loop properly. Apparently, the
only drivers to do this were those using the old 'tnl' module for software
vertex processing.
Now we convert the split pieces of GL_LINE_LOOP prims into GL_LINE_STRIP
primitives so that drivers don't have to worry about the special begin/end
flags. The only time a driver will get a GL_LINE_LOOP prim is when the
whole thing fits in one vertex buffer.
Mostly fixes bug 81174, but not completely. There's another bug somewhere
in the src/gallium/auxiliary/draw/ code. If the piglit lineloop test is
run with -count 4096, rendering is correct, but with -count 4097 there are
stray lines. 4096 is a magic number in the draw code (search for "4096").
Also note that this does not fix long line loops in display lists. The
next patch fixes that.
v2: fix incorrect -1 in vbo_compute_max_verts(), per Charmaine. Remove
incorrect assertion which was added in vbo_copy_vertices().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81174
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49779
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28130
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
As before, use a new 'last_prim' pointer to simplify things. Plus, add
some const qualifiers.
v2: use 'sz' in another place, per Sinclair. And update subject line.
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Use a new 'last_prim' pointer to simplify things.
v2: remove unneeded assert(exec->vtx.prim_count > 0)
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever we got a glColor, glNormal, glTexCoord, etc. call outside a
glBegin/End pair, we'd immediately map a vertex buffer to begin
accumulating vertex data. In some cases, such as with display lists,
this led to excessive vertex buffer mapping. For example, if we have
a display list such as:
glNewList(42, GL_COMPILE);
glBegin(prim);
glVertex2f();
...
glVertex2f();
glEnd();
glEndList();
Then did:
glColor3f();
glCallList(42);
We'd map a vertex buffer as soon as we saw glColor3f but we'd never
actually write anything to it. Note that the vertex position data
was put into a vertex buffer during display list compilation.
With this change, we delay mapping the vertex buffer until we actually
have a vertex to write to it (triggered by a glVertex() call). In the
above case, we no longer map a vertex buffer when setting the color and
calling the list.
For drivers such as VMware's, reducing buffer mappings gives improved
performance.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
Not called from any other file. Rename and move before use.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
Improve readability a bit.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The variable 'i' is a value in [0, MAT_ATTRIB_MAX-1] so subtracting
VERT_ATTRIB_GENERIC0 gave a bogus value and we executed the default
switch clause for all loop iterations.
This doesn't fix any known issues but was clearly incorrect.
Cc: [email protected]
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
Nothing overrides it.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Nothing overrides it.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Nothing overrides it.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Nothing overrides it.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Nothing overrides it.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Nothing overrides it.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Nothing overrides it.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Nothing overrides it.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
| |
Reviewed-by: Iago Toral Quiroga <[email protected]>
|
|
|
|
|
|
|
| |
Generated by sed; no manual changes.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A couple functions are missing because there are no implementations of
them yet. These are:
glFramebufferParameteri (from GL_ARB_framebuffer_no_attachments)
glGetFramebufferParameteriv (from GL_ARB_framebuffer_no_attachments)
glMemoryBarrierByRegion
v2: Rebase on updated dispatch_sanity.cpp test.
v3: Add support for glDraw{Arrays,Elements}Indirect in vbo_exec_array.c.
The updated dispatch_sanity.cpp test discovered this omission.
v4: Rebase on glapi changes.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support in the vbo and array code to handle
double vertex attributes.
v0.2: merge code to handle doubles in vbo layer.
v1: don't use v0, merge api_array elt code.
Acked-by: Ilia Mirkin <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
| |
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
Reviewed-by: Anuj Phogat <[email protected]>
Signed-off-by: Marius Predut <[email protected]>
|