summaryrefslogtreecommitdiffstats
path: root/src/mesa/vbo
Commit message (Collapse)AuthorAgeFilesLines
* vbo: simplify some code in check_draw_elements_data()Brian Paul2016-10-131-5/+4
| | | | | | Use the 'vao' local var in more places. Reviewed-by: Mathias Fröhlich <mathias.froehlich@web.de>
* mesa: rename gl_vertex_attrib_array gl_array_attributesBrian Paul2016-10-131-4/+4
| | | | | | | The structure contains the attributes of a vertex array. The old name was kind of confusing. Reviewed-by: Mathias Fröhlich <mathias.froehlich@web.de>
* mesa: rename gl_vertex_attrib_array::VertexBindingBrian Paul2016-10-131-3/+3
| | | | | | | | | Rename to gl_vertex_attrib_array::BufferBindingIndex because this field is an index into the array of buffer binding points. This makes some code a little easier to follow since there's also a "VertexBinding" field in gl_vertex_array_object. Reviewed-by: Mathias Fröhlich <mathias.froehlich@web.de>
* vbo: increase VBO_SAVE_BUFFER_SIZE from 8k to 256k dwordsTim Rowley2016-09-061-1/+1
| | | | | | | | | | | | Increases the performance of legacy geometry-heavy apps still using display lists. Performance increase for a targeted testcase is on the order of 8x, and applications like ParaView 4.x (5.x uses no longer used display lists) improve by about 10%-20%. Reviewed-by: Mathias Fröhlich <mathias.froehlich@web.de> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* vbo: set draw_idMiklós Máté2016-08-261-0/+1
| | | | | | | | | Fixes conditional jump depending on uninitialized value in si_state_draw.c:593 Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Miklós Máté <mtmkls@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com>
* vbo: fix format string compiler warning for 32-bit machinesJan Ziak2016-08-231-5/+6
| | | | | Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b@gmail.com> Reviewed-by: Brian Paul <brianp@vmware.com>
* vbo: Make #if 0'd debugging code compile.Matt Turner2016-08-221-1/+1
|
* vbo: remove unnecessary max_basevertex computationIlia Mirkin2016-08-181-8/+0
| | | | | | | | The max basevertex is already computed and added into max_index by the caller, _tnl_draw_prims. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* vbo: add basevertex when looking up elements for vbo splittingIlia Mirkin2016-08-181-1/+1
| | | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97351 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* vbo: Remove always true return from vbo_bind_arrays.Mathias Fröhlich2016-08-152-26/+12
| | | | | | Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Eric Anholt <eric@anholt.net>
* mesa: Move check for vbo mapping into api_validate.c.Mathias Fröhlich2016-08-151-7/+1
| | | | | | | | | | | Instead of checking for mapped buffers in vbo_bind_arrays do this check in api_validate.c. This additionally enables printing the draw calls name into the error string. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Eric Anholt <eric@anholt.net>
* mesa: Move _mesa_all_buffers_are_unmapped to arrayobj.c.Mathias Fröhlich2016-08-151-35/+1
| | | | | | | | | | Move the function to check if all vao buffers are unmapped into the vao implementation file. Rename the function to _mesa_all_buffers_are_unmapped. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Eric Anholt <eric@anholt.net>
* vbo: Array draw must not care about glBegin/glEnd vbo mapping.Mathias Fröhlich2016-08-151-17/+1
| | | | | | | | | In array draw do not check if the vertex buffer object that is used to implement immediate mode glBegin/glEnd is mapped. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Eric Anholt <eric@anholt.net>
* vbo: allow DrawElementsBaseVertex in display listsIlia Mirkin2016-08-141-5/+13
| | | | | | | | | Looks like it was missed originally. The multi version is there already. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97331 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Cc: mesa-stable@lists.freedesktop.org
* util: Move format_r11g11b10f.h to src/utilJason Ekstrand2016-08-051-1/+1
| | | | | | | It's used from both mesa main and gallium. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Roland Scheidegger <sroland@vmware.com>
* mesa: Remove set but not used gl_client_array::Stride.Mathias Fröhlich2016-07-314-5/+1
| | | | | | | | The field is only read for printing today and there it was probably a leftover. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Eric Anholt <eric@anholt.net>
* mesa: Remove set but not used gl_client_array::Enabled.Mathias Fröhlich2016-07-314-6/+2
| | | | | | | | The way it is used today does not care about the Enabled flag anymore. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Eric Anholt <eric@anholt.net>
* vbo: Use the VAO array enabled flags in vbo_exec_array.Mathias Fröhlich2016-07-311-7/+8
| | | | | | | | | Instead of gl_client_array::Enabled inside a VAO, directly use the gl_vertex_attrib_array::Enabled value which is the origin of the above. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Eric Anholt <eric@anholt.net>
* vbo: Walk the VAO in check_array_data.Mathias Fröhlich2016-07-311-20/+29
| | | | | | | | | Only a debugging function, but move away from gl_client_array and use the first order information from the VAO. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Eric Anholt <eric@anholt.net>
* vbo: Walk the VAO in print_draw_arrays.Mathias Fröhlich2016-07-311-20/+20
| | | | | | | | | Only a debugging function, but move away from gl_client_array and use the first order information from the VAO. Also make use of gl_vert_attrib_name. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Eric Anholt <eric@anholt.net>
* vbo: Walk the VAO to check for mapped buffers.Mathias Fröhlich2016-07-311-10/+23
| | | | | | | | | Similarily to _mesa_all_varyings_in_vbos walk the VAO to check if we have an illegal mapped buffer object instead of walking all gl_client_arrays. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Eric Anholt <eric@anholt.net>
* vbo: Walk the VAO to see if all varyings are in vbos.Mathias Fröhlich2016-07-311-2/+2
| | | | | | | | | | | | | | | | In vbo_draw_transform_feedback we currently look at exec->array.inputs to determine if all varying vertex attributes reside in vbos. But the vbo_bind_arrays call only happens past the vbo_all_varyings_in_vbos query. Thus we may work on a stale set of client arrays. Using the current VAOs content for this query feels much more logical to me. Additionally with this change mesa makes more use of the information already tracked in the VAO instead of looping across VERT_ATTRIB_MAX vertex arrays. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Eric Anholt <eric@anholt.net>
* vbo: Fix handling of POS/GENERIC0 attributes.Mathias Fröhlich2016-07-271-3/+16
| | | | | | | | | | | | | In case of split primitives we need to restore the original setting of the vtx.attrsz array to make immediate mode attribute array tracking work. v2: Use bool instead of boolean. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Brian Paul <brianp@vmware.com> Tested-by: Brian Paul <brianp@vmware.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96950
* 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 <robdclark@gmail.com> Reviewed-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
* 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 <brianp@vmware.com> Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
* 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 <brianp@vmware.com> Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
* 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" <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* 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" <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* 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 <kenneth@whitecape.org> Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* vbo: avoid leaking prim on vbo bind failureIlia Mirkin2016-05-011-1/+3
| | | | | | | Spotted by Coverity Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Vinson Lee <vlee@freedesktop.org>
* 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 <jordan.l.justen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* 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 <imirkin@alum.mit.edu> Reviewed-by: Dave Airlie <airlied@redhat.com>
* 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 <marek.olsak@amd.com>
* mesa: add USAGE_DISABLE_MINMAX_CACHE flag to buffer UsageHistoryNicolai Hähnle2016-02-031-1/+2
| | | | Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* 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 <chrisf@ijw.co.nz> (v2) Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* 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 <ian.d.romanick@intel.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* mesa: add support for ARB_indirect_parameters draw functionsIlia Mirkin2016-01-071-0/+103
| | | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* glapi: add ARB_indirect_parameters definitionsIlia Mirkin2016-01-071-0/+21
| | | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* 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 <imirkin@alum.mit.edu> Acked-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* vbo: s/GLuint/GLbitfield/ for state bitmasksBrian Paul2016-01-064-4/+4
| | | | Reviewed-by: José Fonseca <jfonseca@vmware.com>
* 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 <anuj.phogat@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* 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 <syeh@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com>
* 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 <imirkin@alum.mit.edu>
* 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 <charmainel@vmware.com>
* 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 <mattst88@gmail.com>
* 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 <jfonseca@vmware.com> Acked-by: Sinclair Yeh <syeh@vmware.com>
* 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 <marek.olsak@amd.com> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
* vbo: add new vbo_compute_max_verts() helper functionBrian Paul2015-10-203-4/+16
| | | | | | Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
* vbo: simplify some code in vbo_exec_End()Brian Paul2015-10-201-4/+3
| | | | | | Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
* 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 <marek.olsak@amd.com> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>