Re: [PATCH] mgag200: Enable atomic gamma lut update

[Jocelyn Falempe <jfalempe@redhat.com>]

On 09/05/2022 18:04, Michel Dänzer wrote:
> On 2022-05-09 16:22, Thomas Zimmermann wrote:
>>
>> It might also make sense to adjust the starting value of the lut table such that its final entry is used for the final entry in the HW palette. For typical gamma ramps ~2, the curve is fairly flat for small values and goes up steeply at high values. (Please correct me if I'm misinterpreting the gamma ramps.)
> 
> I don't think that's accurate. The most common ramp should be a straight line from 0 to the maximum value, and others may be curved toward the top or bottom.
> 
> 
>> For 15-bit case I'd do thing like this.
>>
>>   lut += 7;
>>   for (i < 0; i < 32; ++i, lut += 8) {
>>      // write  lut
>>   }
>>
>> 16-bit is complicated and may better be done in 2 loops
>>
>>   lutr += 7;
>>   lutg += 3;
>>   lutb += 7;
>>   for (i < 0; i < 32; ++i, lutr += 8, lutg += 3, lutb += 8) {
>>     // write  r/g/b lut
>>   }
>>   for (; i < 64; ++i, lutg += 3) {
>>     // write  0/g/0 lut
>>   }
> 
> That'll just drop the first 3-7 entries of the LUT instead of the last ones, i.e. generally the full black entries instead of the full white ones.
> 
> Ideally, the loop should start at 0 and then count as evenly as possible up to 255/63/31. I realize that's tricky though, and I don't have any specific suggestions for how to achieve this offhand.
> 
> 

If you want 32 values from the 256 table, something like this should work:

for (i=0; i<32; i++) {
    lut_index = i * 8 + i / 4;
}

lut_index will have this value:

0, 8, 16, 24, 33, 41, 49, 57, 66, 74, 82, 90, 99, 107, 115, 123, 132, 
140, 148, 156, 165, 173, 181, 189, 198, 206, 214, 222, 231, 239, 247, 255


-- 

Jocelyn