Bug 43096 - r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
Summary: r300g: r300_emit_draw_elements() refusing to render when max_index = 0xffffffff
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-19 13:26 UTC by Tom Stellard
Modified: 2011-11-20 13:16 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Callstack from error message (1.46 KB, text/plain)
2011-11-19 13:26 UTC, Tom Stellard
Details

Description Tom Stellard 2011-11-19 13:26:32 UTC
Created attachment 53692 [details]
Callstack from error message

I'm not exactly sure if this is a bug in r300g or st/mesa, but none of the leader portraits are rendered in Civ4 and this error message is being printed:

r300: Got a huge number of vertices: 310, refusing to render (max_index: -1).

The reason this error message is being printed is because max_index is 0xffffffff, so this if statement at r300_render.c:448 evaluates to true:

if (count >= (1 << 24) || max_index >= (1 << 24)) {
        fprintf(stderr, "r300: Got a huge number of vertices: %i, "
                "refusing to render (max_index: %i).\n", count, max_index);
        return;
}

I'm not sure if the state tracker is wrong for passing 0xffffffff as the max_index or if the driver needs to handle a max_index of 0xffffffff as a special case, because it is the default value for pipe_draw_info->max_index.  I have captured the call stack when this error message is printed and attached it to this bug report.
Comment 1 Marek Olšák 2011-11-19 20:22:03 UTC
Could you try this branch?

git://people.freedesktop.org/~mareko/mesa vbufmgr-fixes
Comment 2 Tom Stellard 2011-11-19 20:48:46 UTC
(In reply to comment #1)
> Could you try this branch?
> 
> git://people.freedesktop.org/~mareko/mesa vbufmgr-fixes

Still they same problem, but now max_index is -2 instead of -1.
Comment 3 Marek Olšák 2011-11-20 07:35:27 UTC
I pushed the branch anyway because it fixes some other bugs.

What happens if you do in r300_draw_vbo:

info.max_index = max_count == ~0 ? 0xffffff : max_count - 1;
Comment 4 Tom Stellard 2011-11-20 08:11:12 UTC
(In reply to comment #3)
> I pushed the branch anyway because it fixes some other bugs.
> 
> What happens if you do in r300_draw_vbo:
> 
> info.max_index = max_count == ~0 ? 0xffffff : max_count - 1;

This fixes the error, but the leader portraits still aren't being rendered, so I guess there is some other problem causing this.  I'll have to bisect to find out exactly what it is.  This bug can be closed once the above fix or something equivalent is committed to mater.
Comment 5 Marek Olšák 2011-11-20 09:33:32 UTC
The problem is there are no vertex attribs which are per-vertex (i.e. not constant and not per-instance), therefore there is nothing to compute the max index from.
Comment 6 Tom Stellard 2011-11-20 09:54:59 UTC
(In reply to comment #4)
> This fixes the error, but the leader portraits still aren't being rendered, so
> I guess there is some other problem causing this.  I'll have to bisect to find
> out exactly what it is.  This bug can be closed once the above fix or something
> equivalent is committed to mater.

I found the real problem, shaders are being failed for having too many varyings / uniforms (Bug 42930 and Bug 43121).  When those shaders compile successfully, the portraits are rendered, and I don't get the "refusing to render" error.
Comment 7 Marek Olšák 2011-11-20 13:16:27 UTC
OK, closing.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.