It looks like a lot of offsets in gallium are really not ready for >32-bit buffer sizes. For example, pipe_buffer->width0 is an unsigned int. However in these cases, there are some semi-legitimate use-cases where a 64-bit offset is still computed, as tested by the draw-elements-base-vertex-neg piglit test. This series fixes up a few instances that need the 64-bit multiplication (on 64-bit platforms). There are probably more, but would be annoying to change without many API changes.
Perhaps an alternative is to make nouveau comply with the broken 32-bit truncation-on-multiply logic, but this was a _giant pain_ to debug, and when 64-bit-sized buffers do come in, or some other similar use-case occurs, I would hate for the person doing that to go through this again. As such I think it makes sense to assume that stuff _can_ be 64-bit even though in practice it usually isn't. [Also it's not exactly fun to try to account for bugs in one piece of code by introducing the exactly-inverse bugs in another piece of code. For example, I do seem to recall that I tried to nuke the ptrdiff_t cast in the nouveau code and that was insufficient.] Ilia Mirkin (2): translate: deal with size overflows by casting to ptrdiff_t util/u_vbuf: correct map offset calculation for crazy offsets src/gallium/auxiliary/translate/translate_generic.c | 2 +- src/gallium/auxiliary/translate/translate_sse.c | 8 ++++++-- src/gallium/auxiliary/util/u_vbuf.c | 2 +- 3 files changed, 8 insertions(+), 4 deletions(-) -- 1.8.3.2 _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
