Comment # 8
on bug 80673
from Hadrien
It seems that what is happening is that the "end" argument is referencing a vertex that does not exist when glDrawRangeElementsBaseVertex is called. The documentation says that "start" and "end" are inclusive indices so I guess a missing "-1" in the game code is the cause of the problem. In the last callstack, the game informs the driver that vertices 0 to 64 (inclusive) should be used for drawing: vbo_exec_DrawRangeElementsBaseVertex(mode=4, start=0, end=64, count=168, type=5123, indices=0x7f22c87bfeb0, basevertex=0) And later the driver will upload data with those arguments: u_vbuf_upload_buffers(mgr=0x7f22efa9e760, start_vertex=0, num_vertices=65, start_instance=0, num_instances=1) So an attempt to upload 65 vertices is done for a range of [0..64], which is correct as per the spec, but in my case the buffer only holds 64 elements. I do not know how the driver can protect itself from such a case. I've been looking at the glVertexPointer API but the client does not inform the driver of the total size of the pointed buffer, so I don't know how to verify this kind of out of bounds errors. The only idea I have would be to scan all indices to get min and max values and issue a warning if they do not fit exactly in the "start" and "end" indices. However this would probably be ineffective as the purpose of "Range" functions seems to be precisely to inform the driver of the range so it does not need to compute it. Moreover, though it is ineffective to include useless vertices in the range, the spec does not seem to forbid it. Sadly, it seems there is nothing to do on the Mesa side. At least I will inform the game developers about my analysis and then close this bug.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
