Am 15.09.2014 22:48, schrieb Dave Airlie: >> >> I never really looked at the big endian stuff so I have no idea if this >> is right. I thought though the channel shift thing now should work >> without endianness awareness if you fetch one 32bit number and then >> break it up into parts with shifts due to the channel information being >> adjusted for big/little endian. I could be wrong though, but if it >> doesn't work that means there's probably some more mixup elsewhere (util >> or llvmpipe code for clearing has its own conversion, and obviously the >> format fetch used for depth texturing needs to match too). >> > > Well I was mainly look at the code in u_format_zs.c that has big > endian handlers, and since this code directly loads from memory I > assumed it would need the same treatment,
Yeah that looks like a reasonable assumption. Maybe they aren't treated like the color non-array formats (should they?). There's a lot of code which needs to match at the end, and some is hardcoded: - depth fetch in llvmpipe - format fetch in gallivm - util_pack_mask_z() and friends used for clearing - the actual clearing (which unlike color doesn't use util code for conversion) in lp_rast_clear_zstencil() - all the autogened conversion code for reading/writing > however it seems a bit more subtle since we regress a few tests, but > pass a couple of hundred more, so I'll see if I can figure out what > else is missing. > Well if it mostly fixes things I'd say go for it. Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
