On 19 May 2010 21:03, Cui, Hunk <hunk....@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 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
