[Intel-gfx] Fwd: State of 10 bits/channel?

[Andrew Lutomirski]

On Fri, Jul 23, 2010 at 8:26 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Thu, 22 Jul 2010 17:34:09 -0400, Andrew Lutomirski <luto at mit.edu> wrote:
>> [resend b/c I used the wrong from address last time]
>>
>> I have a 10 bit/channel monitor (DisplayPort) which works quite nicely
>> in 8 bit mode.  I saw some patches from Peter Clifton related to 10
>> bit support go in awhile ago.
>
> [snip]
>
>> What is the hardware capable of, and what is the state of affairs
>> right now?
>
> AIUI, all the intel chips are capable of driving 30-bit displays. The
> later generations are more flexible and faster with greater bit depth for
> LUTs etc. The output driver support should (in theory) be complete, but it
> hasn't been well tested due to scarcity of suitable displays.

OK.  I'll try to figure out how to program the output driver.  Do we
want to drive outputs at 30 bits even when the primary surface is 24
bits?  (Benefit: 10-bit LUTs.  Disadvantage: Could break existing
setups.)

Expect lots of questions from me when I run into things that are
unclear or wrong in the docs.

>
>>  I'm running 2.6.35-rc4+ with a hacked up xf86-video-intel
>> with this patch:
>
> Please submit this as a format-patch to the list for inclusion.

You only say that because there's one line too few of context to see
how dumb the patch is.  I'll fix and submit.

>
>> With that patch and DefaultDepth 30, I get a mostly working system,
>> but there's no direct rendering (seems to be disabled because "DRI is
>> disabled because it runs only at depths 16 and 24") title bars on
>> gnome-terminal draw incorrectly.
>
> Hmm, the render paths should work on 10bpc surfaces. Please do file bugs
> for the failures.

Will do.  I'll also see how close to working I can get DRI in 30-bit
mode.  (Enabling it right now exposes a silly bug in the compiz
startup scripts which results in having no window manager at all on
F13.  I'll figure out whose bug it is and file that one as well.)

>
> --
> Chris Wilson, Intel Open Source Technology Centre
>