No good reason really, simply that the original functions seemed simpler
for the case of in-place swapping since you don't have to pass the dst
parameter explicitly, so I figured there was a marginal gain in letting
them stay, specially since their implementation is just an inline call
to the
On Wed, 2014-11-19 at 14:15 -0600, Patrick Baggett wrote:
On Tue, Nov 18, 2014 at 3:23 AM, Iago Toral Quiroga
ito...@igalia.com wrote:
We have _mesa_swap{2,4} but these do in-place byte-swapping
only. The new
functions receive an extra parameter so we can swap
On Thu, Nov 20, 2014 at 12:48 AM, Iago Toral ito...@igalia.com wrote:
On Wed, 2014-11-19 at 14:15 -0600, Patrick Baggett wrote:
On Tue, Nov 18, 2014 at 3:23 AM, Iago Toral Quiroga
ito...@igalia.com wrote:
We have _mesa_swap{2,4} but these do in-place byte-swapping
The restrict keyword is a C99 thing and I don't think it's supported in
MSVC so that would be a problem. If it won't build with MSVC then it's a
non-starter. If MSVC can handle restrict, then I don't know that I care
much either way about 2 functions or 4
MSVC uses __restrict which
Any reason why you added 2 new functions, instead of just altering the ones
we have and updating where they are used?
On Tue, Nov 18, 2014 at 1:23 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
We have _mesa_swap{2,4} but these do in-place byte-swapping only. The new
functions receive an
On Tue, Nov 18, 2014 at 3:23 AM, Iago Toral Quiroga ito...@igalia.com
wrote:
We have _mesa_swap{2,4} but these do in-place byte-swapping only. The new
functions receive an extra parameter so we can swap bytes on a source
input array and store the results in a (possibly different) destination
We have _mesa_swap{2,4} but these do in-place byte-swapping only. The new
functions receive an extra parameter so we can swap bytes on a source
input array and store the results in a (possibly different) destination
array.
This is useful to implement byte-swapping in pixel uploads, since in this
