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
