summaryrefslogtreecommitdiffstats
path: root/src/mesa/vbo
Commit message (Collapse)AuthorAgeFilesLines
* vbo: fix attr resetRob Clark2016-07-063-7/+10
| | | | | | | | | | | | | | | In bc4e0c4 (vbo: Use a bitmask to track the active arrays in vbo_exec*.) we stopped looping over all the attributes and resetting all slots. Which exposed an issue in vbo_exec_bind_arrays() for handling GENERIC0 vs. POS. Split out a helper which can reset a particular slot, so that vbo_exec_bind_arrays() can re-use it to reset POS. This fixes an issue with 0ad (and possibly others). Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Mathias Fröhlich <[email protected]>
* vbo: Use a bitmask to track the active arrays in vbo_save*.Mathias Fröhlich2016-06-163-55/+69
| | | | | | | | | | | The use of a bitmask makes functions iterating only active attributes less visible in profiles. v2: Use _mesa_bit_scan{,64} instead of open coding. v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* vbo: Use a bitmask to track the active arrays in vbo_exec*.Mathias Fröhlich2016-06-163-70/+79
| | | | | | | | | | | The use of a bitmask makes functions iterating only active attributes less visible in profiles. v2: Use _mesa_bit_scan{,64} instead of open coding. v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* vbo: Declare the index range invalid for DrawTransformFeedbackJason Ekstrand2016-05-231-1/+1
| | | | | | | | | | Right now, we're setting the range to [0, 0] which is obviously bogus. Instead, we should set it to be invalid like we do for DrawIndirect. Cc: "11.1 11.2" <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* vbo: Declare the index range invalid for DrawIndirectJason Ekstrand2016-05-231-1/+1
| | | | | | | | | | | | | | Right now, we're just setting the range to [0, MAX_UINT32] which, while correct isn't helpful. With DrawIndirect, you can't really know what the actual range is so we may as well flag it as being an invalid range. This is what we do for draws with index buffer which is similar (the indices aren't statically known) if a bit simpler. Cc: "11.1 11.2" <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa/vbo: fix check for zero aliases with 2/10/10/10Dave Airlie2016-05-101-1/+1
| | | | | | | | | This fixes: GL33-CTS.gtf33.GL3Tests.vertex_type_2_10_10_10_rev.vertex_type_2_10_10_10_rev_attrib Reviewed-by: Kenneth Graunke <[email protected]> Cc: [email protected] Signed-off-by: Dave Airlie <[email protected]>
* vbo: avoid leaking prim on vbo bind failureIlia Mirkin2016-05-011-1/+3
| | | | | | | Spotted by Coverity Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Vinson Lee <[email protected]>
* vbo: Return INVALID_OPERATION during draw with a mapped bufferJordan Justen2016-04-272-47/+42
| | | | | | | | | | | | | | | | Fixes the OpenGLES 3.1 CTS: * ESEXT-CTS.draw_elements_base_vertex_tests.invalid_mapped_bos Because this is triggering the error message after the normal API validation phase, we don't have the API function name available, and therefore we generate an error message without the draw call name: Mesa: User error: GL_INVALID_OPERATION in draw call (vertex buffers are mapped) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95142 Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: expose EXT_base_instance in ES3 contextsIlia Mirkin2016-04-031-1/+1
| | | | | | | | 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]>
* vbo: disable the minmax cache when the hit rate is lowNicolai Hähnle2016-02-031-2/+32
| | | | | | | | | | | | | | | | | | 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]>
* mesa: add USAGE_DISABLE_MINMAX_CACHE flag to buffer UsageHistoryNicolai Hähnle2016-02-031-1/+2
| | | | Reviewed-by: Marek Olšák <[email protected]>
* vbo: cache/memoize the result of vbo_get_minmax_indices (v3)Nicolai Hähnle2016-02-032-0/+171
| | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* vbo: move vbo_get_minmax_indices into its own source fileNicolai Hähnle2016-02-032-148/+179
| | | | | | | | 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]>
* mesa: add support for ARB_indirect_parameters draw functionsIlia Mirkin2016-01-071-0/+103
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* glapi: add ARB_indirect_parameters definitionsIlia Mirkin2016-01-071-0/+21
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* vbo: create a new draw function interface for indirect drawsIlia Mirkin2016-01-074-75/+89
| | | | | | | | | | | | | | 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]>
* vbo: s/GLuint/GLbitfield/ for state bitmasksBrian Paul2016-01-064-4/+4
| | | | Reviewed-by: José Fonseca <[email protected]>
* mesa/vbo: Add draw_id field to struct _mesa_primKristian Høgsberg Kristensen2015-12-292-0/+5
| | | | | | | | | | 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]>
* vbo: fix another GL_LINE_LOOP bugBrian Paul2015-11-042-2/+10
| | | | | | | | | | | | | | | | | 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]>
* mesa: expose support for OES/EXT_draw_elements_base_vertex to OpenGL ESRyan Houdek2015-11-011-3/+10
| | | | | | | This has been tested with the piglits in the mailing list and on the Dolphin emulator. Reviewed-by: Ilia Mirkin <[email protected]>
* vbo: replace assertion with conditional in vbo_compute_max_verts()Brian Paul2015-10-281-1/+2
| | | | | | | | | 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]>
* vbo: optimize vertex copying when 'wrapping'Brian Paul2015-10-222-17/+14
| | | | | | | 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]>
* vbo: convert display list GL_LINE_LOOP prims to GL_LINE_STRIPBrian Paul2015-10-201-0/+53
| | | | | | | | | | | | | 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]>
* vbo: fix GL_LINE_LOOP stray line bugBrian Paul2015-10-203-3/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* vbo: add new vbo_compute_max_verts() helper functionBrian Paul2015-10-203-4/+16
| | | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]>
* vbo: simplify some code in vbo_exec_End()Brian Paul2015-10-201-4/+3
| | | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]>
* vbo: simplify some code in vbo_copy_vertices()Brian Paul2015-10-201-6/+5
| | | | | | | | | | | 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]>
* vbo: simplify some code in vbo_exec_wrap_buffers()Brian Paul2015-10-201-6/+4
| | | | | | | | | | 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]>
* vbo: replace the comment on vbo_copy_vertices()Brian Paul2015-10-201-3/+7
| | | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]>
* vbo: make vbo_exec_vtx_wrap() staticBrian Paul2015-10-202-3/+2
| | | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]>
* vbo: remove unneeded ctx parameter for merge_prims()Brian Paul2015-10-201-3/+2
| | | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Sinclair Yeh <[email protected]>
* vbo: reduce number of vertex buffer mappings for vertex attributesBrian Paul2015-10-201-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* vbo: make void vbo_exec_BeginVertices() staticBrian Paul2015-10-132-21/+20
| | | | | | Not called from any other file. Rename and move before use. Reviewed-by: Marek Olšák <[email protected]>
* vbo: document vbo_exec_context fieldsBrian Paul2015-10-131-7/+8
| | | | Reviewed-by: Marek Olšák <[email protected]>
* vbo: minor clean-ups for vbo_exec_fixup_vertex()Brian Paul2015-10-131-2/+5
| | | | Reviewed-by: Marek Olšák <[email protected]>
* vbo: add assertion in ATTR_UNION macroBrian Paul2015-10-131-0/+3
| | | | Reviewed-by: Marek Olšák <[email protected]>
* vbo: add comments, braces in ATTR_UNION() in vbo_exec_api.cBrian Paul2015-10-131-2/+12
| | | | Reviewed-by: Marek Olšák <[email protected]>
* vbo: fix whitespace in vbo_exec_draw.cBrian Paul2015-10-131-13/+12
| | | | Reviewed-by: Marek Olšák <[email protected]>
* vbo: move 'tmp' var initializationBrian Paul2015-10-131-1/+2
| | | | | | Improve readability a bit. Reviewed-by: Marek Olšák <[email protected]>
* vbo: improve fprintf() formattingBrian Paul2015-10-131-1/+1
| | | | Reviewed-by: Marek Olšák <[email protected]>
* vbo: simplify vertex array initializations in vbo_context.cBrian Paul2015-10-131-52/+43
| | | | Reviewed-by: Marek Olšák <[email protected]>
* vbo: get rid of needless NR_MAT_ATTRIBS constantBrian Paul2015-10-131-6/+3
| | | | Reviewed-by: Marek Olšák <[email protected]>
* vbo: fix incorrect switch statement in init_mat_currval()Brian Paul2015-10-131-1/+1
| | | | | | | | | | | | 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]>
* mesa: remove Driver.EndCallListMarek Olšák2015-10-033-10/+1
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.BeginCallListMarek Olšák2015-10-033-2/+1
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.EndListMarek Olšák2015-10-033-2/+1
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.NewListMarek Olšák2015-10-033-2/+1
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.NotifySaveBeginMarek Olšák2015-10-034-7/+2
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.SaveFlushVerticesMarek Olšák2015-10-034-3/+2
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.FlushVerticesMarek Olšák2015-10-034-3/+11
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>