Do not display the screensaver

[Yang Zhao]

On 19 May 2010 21:03, Cui, Hunk <Hunk.Cui at amd.com> wrote:
>        What is mean about the server's internal representation is abstracted away from the driver's representation? I don't understand it. Can you particular explain it. I know the R,G,B originality values are 16 bits per channel. When the values are transfered to the driver layer, they will be dealed with through "val = (*red << 8) | *green | (*blue>>8);" because the "val" will be writen into Gamma correction RAM register (the type of hardware register: Each of the entries are made up of corrections for R/G/B. Within the DWORD, the red correction is in b[23:16], green in b[15:8] and blue in b[7:0]).
>        Why the driver is allowed to truncate? And why not be transfered by R/G/B former values. Can you know that?
>
> BTW: Behrmann, "Three one dimensional look up tables (LUT) each of 8-bit resolution would not make much sense in this scenario." Please particular explain it. Thank you for your earnest reply.

The term "gamma" in this discussion is actually misleading: all the
gamma-related calls, as they are currently implemented, eventually
results in writes to the hardware LUT which translates pixel values to
actual electrical output values. "Gamma correction" is just one of the
things you can do by modifying the values in the table.

The precision of the LUT depends on the hardware. Radeons, for
example, have 10 bits of precision per channel. CARD16 is an
appropriate upper bound for the range of precisions that will
realistically be in use.  Also keep in mind that these LUTs were used
primarily to drive analog outputs not too long ago, which have much,
much higher precisions than their digital counter parts.

A client makes a "gamma correction" call, server generates a new LUT
with 16 bits of precision per channel, then the driver takes this and
truncates to whatever precision the hardware can actually take.


-- 
Yang Zhao
http://yangman.ca