What's the point of min/max ranges? Because if you have a huge vertex buffer and you only draw few indices you may choose to upload to VRAM only the vertices actually referred. Applications do this. And for certain hardware uploads are very slow, so it is an worthwhile optimization.
Efficiency is just or more important goal than principles like "state tracker should sanitize". There is hardware that can handle buffers with out of bounds indices without crashing. The APIs we expose also make the same promise. In such situation the shortcomings on one hardware should not be taxed to all. Furthermore, if you need scan/clamp the indices in an index buffer then it might be worthwhile to do it in cached memory, and copy to uncached memory in the process. Often it is necessary to do software vertex processin fallbacks, so even for hardware that cannot do it there might draw calls where that's not necessary for the state tracker to do it. IMO, this entails too much hardware knowledge to be done both generally and efficiently by the state tracker. The "state tracker should sanitize" principle derives from our desire to share code as much as possible. But there is more than one way to share code. In this case it should be a pip driver auxiliary library. Jose ________________________________________ From: Corbin Simpson [mostawesomed...@gmail.com] Sent: Saturday, March 13, 2010 0:06 To: Keith Whitwell Cc: mesa3d-...@lists.sf.net Subject: Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds. This seems to be at odds with the idea that the pipe driver receives pre-sanitized inputs. If this patch is reverted: - I can't trust the min and max elts, because they're set to ~0 - I can't just use the vertex buffer sizes, because they're set to ~0 So I have to do the maths myself, guessing just like st/mesa guesses. Maybe this is specific to Radeons, but I *always* need those values. I don't mind this, but IMO it *must* be doc'd, "The minimum and maximum index limits passed to draw_elements and draw_range_elements may be invalid," and really, at that point, why are we even passing them? Seems absurd to me. :3 Posting from a mobile, pardon my terseness. ~ C. On Mar 12, 2010 5:40 AM, "Keith Whitwell" <kei...@vmware.com<mailto:kei...@vmware.com>> wrote: On Fri, 2010-03-12 at 02:54 -0800, Corbin Simpson wrote: > Module: Mesa > Branch: master > Commit: 50876ddaaff72a324ac45e255985e0f84e108594 > URL: > http://cgit.freedesktop.org/mesa/mesa/commit/?id=50876ddaaff72a324ac45e255985e0f84e108594 > > Author: Corbin Simpson > <mostawesomed...@gmail.com<mailto:mostawesomed...@gmail.com>> > Date: Fri Mar 12 02:51:40 2010 -0800 > > st/mesa: Always recalculate invalid index bounds. > > These should always be sanitized before heading towards the pipe driver, > and if the calling function explicitly marked them as invalid, we need > to regenerate them. > > Allows r300g to properly pass a bit more of Wine's d3d9 testing without > dropping stuff on the floor. > > --- > > src/mesa/state_tracker/st_draw.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/mesa/state_tracker/st_draw.c > b/src/mesa/state_tracker/st_draw.c > index 8b01272..d81b361 100644 > --- a/src/mesa/state_tracker/st_draw.c > +++ b/src/mesa/state_tracker/st_draw.c > @@ -542,9 +542,9 @@ st_draw_vbo(GLcontext *ctx, > assert(ctx->NewState == 0x0); > > /* Gallium probably doesn't want this in some cases. */ > - if (!index_bounds_valid) > - if (!vbo_all_varyings_in_vbos(arrays)) > - vbo_get_minmax_index(ctx, prims, ib, &min_index, &max_index); > + if (index_bounds_valid != GL_TRUE) { > + vbo_get_minmax_index(ctx, prims, ib, &min_index, &max_index); > + } Corbin, This isn't really desirable. Ideally this range checking should be pushed into pipe driver, because it's an expensive operation that is not necessary on a lot of hardware. # Specifically, vertex fetch hardware can often be set up with the min/max permissible index bounds to avoid accessing vertex data outside of the bound VB's. This can be achieved by examining the VBs, with min_index == 0, max_index = vb.size / vb.stride. The case where we need to calculate them internally is if some data is not in a VB, meaning we can't guess what the legal min/max values are. Also note that we need that min/max information to be able to upload the data to a VB. So, I think the code was probably correct in the original version - defer the minmax scan to the hardware driver, which may or may not need it. But maybe there is a better way to let the driver know that we are not providing this information. Keith ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
