On Fri, Nov 24, 2017 at 8:38 AM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Thu, Nov 23, 2017 at 03:14:46PM -0500, Ilia Mirkin wrote: >> On Thu, Nov 23, 2017 at 2:09 PM, Ville Syrjälä >> <ville.syrjala@xxxxxxxxxxxxxxx> wrote: >> > On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote: >> >> We need to shift the values up, otherwise we'd end up with a negative >> >> shift. This works for up-to 16-bit components, which is fine for now. >> > >> > Shouldn't we actually replicate the high bits in the low bits? >> >> Not entirely sure what you're proposing... >> >> Ideally we wouldn't be lazy and pass e.g. 16-bit values to MAKE_RGBA >> which would then shift down as necessary (and even there, you could >> end up with off-by-1's maybe?). For e.g. 0xff, that should become >> 0x3ff but with my code will become 0x3fc. > > Exactly the issue. > >> But for other values, it's >> less clear what to do with the low bits. I figured it didn't really >> matter. >> >> Do you have a concrete proposal? > > The usual thing would be just > > (value) * 0x3ff / 0xff > > or > > ((value) << 2) | ((value) >> 6) The latter method is interesting, it slowly biases from rounding down to rounding up as you go through the range. Clever. I guess I could change my function to use (value << 8) | value and then use that to shift around. I'll send a v2. -ilia _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
