The overriding goal is to avoid the expense of computing this in software when the hardware can do the bounds check.
I guess we could add a PIPE_CAP query to ask the driver if it can do bounds checking and if it can't, do it in the state tracker. But I think Keith's interested in minimizing queries like this. Hence, try to do it in the driver. I think it should be easy to write a re-usable utility function to do the checks. If you're seeing ~0, that means the Mesa VBO module has not computed the bounds, and/or the user didn't provide them. I'd have to check the code. If vertex data is coming from regular memory and not a VBO we have no idea what the legal bounds are. -Brian On Fri, Mar 12, 2010 at 5:06 PM, Corbin Simpson <mostawesomed...@gmail.com> wrote: > 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> 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> >> 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 > > ------------------------------------------------------------------------------ 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
