Re: Nouveau Digest, Vol 131, Issue 3

Re: Nouveau Digest, Vol 131, Issue 3

[Mario Kleiner]

On 03/01/2018 07:21 PM, nouveau-request@lists.freedesktop.org wrote:
> 
> Message: 1
> Date: Thu, 1 Mar 2018 08:15:55 -0500
> From: Ilia Mirkin <imirkin@alum.mit.edu>
> To: Mario Kleiner <mario.kleiner.de@gmail.com>
> Cc: nouveau <nouveau@lists.freedesktop.org>
> Subject: Re: [Nouveau] [PATCH] Fix colormap handling at screen depth
> 	30.
> Message-ID:
> 	<CAKb7UvhnUF6W41vXHpC+Q+jVSROgnHuxd8CzvfOGHmYSq_xTHQ@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> 
> NVLoadPalette is pretty hard-coded to 256. I haven't looked at what
> all xf86HandleColormaps does, but it seems pretty suspicious. Also

It's also pretty dead :). NVLoadPalette is not ever used, because 
nouveau hooks up the .gamma_set function in xf86CrtcFuncsRec, so 
xf86HandleColormaps ignores the NVLoadPalette pointer. Iow. dead code 
that can be removed. I'll send some follow up patch, once this one is 
in. We have similar dead code in intel-ddx and modesetting-ddx which 
only serves to confuse the reader.

> note that the kernel currently only exposes a 256-sized LUT to
> userspace, even for 10bpc modes.
> 

Yes, but that doesn't matter. In xbgr2101010 mode, the gpu seems to 
properly interpolate between the 256 (or 257) hw lut slots, as far as my 
measurments go. The X-Server maintains separate color palettes, 
per-x-screen xf86vidmode gamma lut's and per-crtc RandR gamma lut's and 
munches them together to produce the final 256 slot hw lut for the 
kernel, up/downsampling if needed. So adapting the values for 
xf86HandleColorMaps() is about properly sizing those internal palette's 
and lut's to avoid out-of-bounds segfaults or loss of precision 
somewhere in the whole multi-step remapping procedure, because one of 
the server internal tables is a bottleneck with too little slots.

This variant is the one that avoids crashes and also visual artifacts 
that i at least observed on tesla gpu's at depth 30.

One weird thing i still observed though is that in depth 30 xbgr2101010 
scanout mode nouveau used dithering when i tried to output a linear 
intensity ramp, despite me disabling dithering via the xrandr property. 
But that is an unrelated problem.

-mario

> On Thu, Mar 1, 2018 at 1:31 AM, Mario Kleiner
> <mario.kleiner.de@gmail.com> wrote:
>> The various clut handling functions like a setup
>> consistent with the x-screen color depth. Otherwise
>> we observe improper sampling in the gamma tables
>> at depth 30.
>>
>> Tested at depths 16, 24 and 30 and tested at depths
>> 24 and 30 that xgamma and gamma table animations work,
>> and with measurement equipment to make sure identity
>> gamma ramps actually are identity mappings at the output.
>>
>> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
>> ---
>>   src/nv_driver.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/nv_driver.c b/src/nv_driver.c
>> index 32062eb..4fcd4c1 100644
>> --- a/src/nv_driver.c
>> +++ b/src/nv_driver.c
>> @@ -1568,8 +1568,8 @@ NVScreenInit(SCREEN_INIT_ARGS_DECL)
>>           * Must follow initialization of the default colormap
>>           */
>>          if (xf86_config->num_crtc &&
>> -           !xf86HandleColormaps(pScreen, 256, 8, NVLoadPalette,
>> -                                NULL, CMAP_PALETTED_TRUECOLOR))
>> +           !xf86HandleColormaps(pScreen, 1 << pScrn->rgbBits, pScrn->rgbBits,
>> +                                NVLoadPalette, NULL, CMAP_PALETTED_TRUECOLOR))
>>                  return FALSE;
>>
>>          /* Report any unused options (only for the first generation) */
>> --
>> 2.7.4
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Nouveau Digest, Vol 131, Issue 3

[Ilia Mirkin]

On Fri, Mar 2, 2018 at 5:16 PM, Mario Kleiner
<mario.kleiner.de@gmail.com> wrote:
> On 03/01/2018 07:21 PM, nouveau-request@lists.freedesktop.org wrote:
>>
>>
>> Message: 1
>> Date: Thu, 1 Mar 2018 08:15:55 -0500
>> From: Ilia Mirkin <imirkin@alum.mit.edu>
>> To: Mario Kleiner <mario.kleiner.de@gmail.com>
>> Cc: nouveau <nouveau@lists.freedesktop.org>
>> Subject: Re: [Nouveau] [PATCH] Fix colormap handling at screen depth
>>         30.
>> Message-ID:
>>
>> <CAKb7UvhnUF6W41vXHpC+Q+jVSROgnHuxd8CzvfOGHmYSq_xTHQ@mail.gmail.com>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> NVLoadPalette is pretty hard-coded to 256. I haven't looked at what
>> all xf86HandleColormaps does, but it seems pretty suspicious. Also
>
>
> It's also pretty dead :). NVLoadPalette is not ever used, because nouveau
> hooks up the .gamma_set function in xf86CrtcFuncsRec, so xf86HandleColormaps
> ignores the NVLoadPalette pointer. Iow. dead code that can be removed. I'll
> send some follow up patch, once this one is in. We have similar dead code in
> intel-ddx and modesetting-ddx which only serves to confuse the reader.
>
>> note that the kernel currently only exposes a 256-sized LUT to
>> userspace, even for 10bpc modes.
>>
>
> Yes, but that doesn't matter. In xbgr2101010 mode, the gpu seems to properly
> interpolate between the 256 (or 257) hw lut slots, as far as my measurments
> go. The X-Server maintains separate color palettes, per-x-screen xf86vidmode
> gamma lut's and per-crtc RandR gamma lut's and munches them together to
> produce the final 256 slot hw lut for the kernel, up/downsampling if needed.

OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set
still only gets called with a 256-entry LUT? If so, that works nicely
here, but is not intuitive :)

> So adapting the values for xf86HandleColorMaps() is about properly sizing
> those internal palette's and lut's to avoid out-of-bounds segfaults or loss
> of precision somewhere in the whole multi-step remapping procedure, because
> one of the server internal tables is a bottleneck with too little slots.
>
> This variant is the one that avoids crashes and also visual artifacts that i
> at least observed on tesla gpu's at depth 30.
>
> One weird thing i still observed though is that in depth 30 xbgr2101010
> scanout mode nouveau used dithering when i tried to output a linear
> intensity ramp, despite me disabling dithering via the xrandr property. But
> that is an unrelated problem.

It's sending 8bpc data out to the screen, unless you're using a DP
monitor (and probably would need a Kepler GPU for that anyways).
Although setting dither to off should still kill the dithering...
probably some experimentation required.

I'm pretty sure I could tell that it was dithering for me on Kepler.
When I added support for 10bpc dither, the dither effect went away
(and it looked no different than the 8bpc gradient). I didn't try
explicitly disabling dithering -- I'll try that tonight and see what
happens (except I've got a Fermi plugged in now).

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Nouveau Digest, Vol 131, Issue 3

[Mario Kleiner]

On 03/02/2018 11:29 PM, Ilia Mirkin wrote:
> On Fri, Mar 2, 2018 at 5:16 PM, Mario Kleiner
> <mario.kleiner.de@gmail.com> wrote:
>> On 03/01/2018 07:21 PM, nouveau-request@lists.freedesktop.org wrote:
>>>
>>>
>>> Message: 1
>>> Date: Thu, 1 Mar 2018 08:15:55 -0500
>>> From: Ilia Mirkin <imirkin@alum.mit.edu>
>>> To: Mario Kleiner <mario.kleiner.de@gmail.com>
>>> Cc: nouveau <nouveau@lists.freedesktop.org>
>>> Subject: Re: [Nouveau] [PATCH] Fix colormap handling at screen depth
>>>          30.
>>> Message-ID:
>>>
>>> <CAKb7UvhnUF6W41vXHpC+Q+jVSROgnHuxd8CzvfOGHmYSq_xTHQ@mail.gmail.com>
>>> Content-Type: text/plain; charset="UTF-8"
>>>
>>> NVLoadPalette is pretty hard-coded to 256. I haven't looked at what
>>> all xf86HandleColormaps does, but it seems pretty suspicious. Also
>>
>>
>> It's also pretty dead :). NVLoadPalette is not ever used, because nouveau
>> hooks up the .gamma_set function in xf86CrtcFuncsRec, so xf86HandleColormaps
>> ignores the NVLoadPalette pointer. Iow. dead code that can be removed. I'll
>> send some follow up patch, once this one is in. We have similar dead code in
>> intel-ddx and modesetting-ddx which only serves to confuse the reader.
>>
>>> note that the kernel currently only exposes a 256-sized LUT to
>>> userspace, even for 10bpc modes.
>>>
>>
>> Yes, but that doesn't matter. In xbgr2101010 mode, the gpu seems to properly
>> interpolate between the 256 (or 257) hw lut slots, as far as my measurments
>> go. The X-Server maintains separate color palettes, per-x-screen xf86vidmode
>> gamma lut's and per-crtc RandR gamma lut's and munches them together to
>> produce the final 256 slot hw lut for the kernel, up/downsampling if needed.
> 
> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set
> still only gets called with a 256-entry LUT? If so, that works nicely
> here, but is not intuitive :)

Yes. Lots of remapping in the server, i get dizzy everytime i look at 
it, and forget almost immediately how stuff fits together when i don't 
look at it. Anyway, the final downsampling from 1024 -> 256 hw lut 
happens in xf86RandR12CrtcComputeGamma(), see

https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5f9fcd50a999a00128c0cc3f6e7d1f66182c9d5

for the latest. I'll propose that one to get cherry-picked into the 
server-1.19 branch as well.

> 
>> So adapting the values for xf86HandleColorMaps() is about properly sizing
>> those internal palette's and lut's to avoid out-of-bounds segfaults or loss
>> of precision somewhere in the whole multi-step remapping procedure, because
>> one of the server internal tables is a bottleneck with too little slots.
>>
>> This variant is the one that avoids crashes and also visual artifacts that i
>> at least observed on tesla gpu's at depth 30.
>>
>> One weird thing i still observed though is that in depth 30 xbgr2101010
>> scanout mode nouveau used dithering when i tried to output a linear
>> intensity ramp, despite me disabling dithering via the xrandr property. But
>> that is an unrelated problem.
> 
> It's sending 8bpc data out to the screen, unless you're using a DP
> monitor (and probably would need a Kepler GPU for that anyways).

I think a long time ago i tested 10 bpc output over VGA with the 
proprietary driver on GeForce 8800, and the current readme for the 
NVidia blob says it can do 10 bpc over VGA and DisplayPort, but only 
dithering over DVI and HDMI. I think i read somewhere that at least 
Pascal could do some deep color output over HDMI as well, which makes 
sense for HDMI-based HDR-10 support.

> Although setting dither to off should still kill the dithering...
> probably some experimentation required.

Yes. I can only test the 10 bpc -> 8 bpc dithered output here, as i 
don't have a native 10 bpc panel available atm. But measurements with 
the photometer confirmed 10 bpc, ie. the photometer is fooled by the 
dithering just as well as the human eye, as it integrates over an area 
of pixels. The dithering is good enough to at least test the whole stack.

I also have a "Datapixx" device which allows to capture the 8 bpc DVI-D 
signal and send it back to the host for finding out what actually goes 
out of the DVI connector, so i can check things like if the gamma ramps 
do what they should, or if dithering is active. However, the device is 
restricted to 8 bpc, so i wouldn't be able to look at a true 10 bpc 
stream (DP/HDMI deep color etc.).

-mario

> 
> I'm pretty sure I could tell that it was dithering for me on Kepler.
> When I added support for 10bpc dither, the dither effect went away
> (and it looked no different than the 8bpc gradient). I didn't try
> explicitly disabling dithering -- I'll try that tonight and see what
> happens (except I've got a Fermi plugged in now).
> 
>    -ilia
> 
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Nouveau Digest, Vol 131, Issue 3

[Ilia Mirkin]

On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
<mario.kleiner.de@gmail.com> wrote:
> On 03/02/2018 11:29 PM, Ilia Mirkin wrote:
>> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set
>> still only gets called with a 256-entry LUT? If so, that works nicely
>> here, but is not intuitive :)
>
> Yes. Lots of remapping in the server, i get dizzy everytime i look at it,
> and forget almost immediately how stuff fits together when i don't look at
> it. Anyway, the final downsampling from 1024 -> 256 hw lut happens in
> xf86RandR12CrtcComputeGamma(), see
>
> https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5f9fcd50a999a00128c0cc3f6e7d1f66182c9d5
>
> for the latest. I'll propose that one to get cherry-picked into the
> server-1.19 branch as well.

Hrmph. That means we should try to adjust the gamma_set helper to do
the sampling when receiving a 1024-sized LUT, if people will use older
X servers (seems likely). Should hopefully be straightforward, to
handle just that one case.

>> It's sending 8bpc data out to the screen, unless you're using a DP
>> monitor (and probably would need a Kepler GPU for that anyways).
>
>
> I think a long time ago i tested 10 bpc output over VGA with the proprietary
> driver on GeForce 8800, and the current readme for the NVidia blob says it
> can do 10 bpc over VGA and DisplayPort, but only dithering over DVI and
> HDMI.

I think that 10bpc HDMI support came with HDMI 1.3. Older devices (esp
Tesla era) won't support that. Intuitively seems like it should Just
Work (tm) over VGA. Not sure which DP version supported 10bpc+.

> I think i read somewhere that at least Pascal could do some deep color
> output over HDMI as well, which makes sense for HDMI-based HDR-10 support.

I believe Kepler+ devices (and perhaps GF119 as well) should support
higher bpc over HDMI. However there's no support for that in nouveau
right now. I happen to have a monitor (TV) that advertises 12bpc
support, so I may play with it.

Here's how dithering is controlled:

https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml#L435

(and also exposed in the public display class docs at
http://download.nvidia.com/open-gpu-doc/Display-Class-Methods/2/ )

In theory turning off dithering should also flip off that ENABLE bit,
but perhaps we messed something up. Or HDMI is extra-special and
doesn't respect that bit and always has it enabled.

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Nouveau Digest, Vol 131, Issue 3

[Mario Kleiner]

On 03/03/2018 12:59 AM, Ilia Mirkin wrote:
> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
> <mario.kleiner.de@gmail.com> wrote:
>> On 03/02/2018 11:29 PM, Ilia Mirkin wrote:
>>> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set
>>> still only gets called with a 256-entry LUT? If so, that works nicely
>>> here, but is not intuitive :)
>>
>> Yes. Lots of remapping in the server, i get dizzy everytime i look at it,
>> and forget almost immediately how stuff fits together when i don't look at
>> it. Anyway, the final downsampling from 1024 -> 256 hw lut happens in
>> xf86RandR12CrtcComputeGamma(), see
>>
>> https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5f9fcd50a999a00128c0cc3f6e7d1f66182c9d5
>>
>> for the latest. I'll propose that one to get cherry-picked into the
>> server-1.19 branch as well.
> 
> Hrmph. That means we should try to adjust the gamma_set helper to do
> the sampling when receiving a 1024-sized LUT, if people will use older
> X servers (seems likely). Should hopefully be straightforward, to
> handle just that one case.

I think we never receive anything but a 256 slot LUT via gamma_set 
afaics? The server initializes xf86Crtc's gamma_size to 256 at startup, 
and none of the ddx'es ever overrides that with actual info from the kernel.

What happens on older servers without that patch iff color depth 30 is 
selected is simply that the gamma table updates no-op, so the server 
runs with an identity gamma table setup at startup. Not perfect, but 
also not that bad, given that probably most people run their setups with 
a gamma of 1.0 anyway. At default depth 24 stuff works as usual.

> 
>>> It's sending 8bpc data out to the screen, unless you're using a DP
>>> monitor (and probably would need a Kepler GPU for that anyways).
>>
>>
>> I think a long time ago i tested 10 bpc output over VGA with the proprietary
>> driver on GeForce 8800, and the current readme for the NVidia blob says it
>> can do 10 bpc over VGA and DisplayPort, but only dithering over DVI and
>> HDMI.
> 
> I think that 10bpc HDMI support came with HDMI 1.3. Older devices (esp
> Tesla era) won't support that. Intuitively seems like it should Just
> Work (tm) over VGA. Not sure which DP version supported 10bpc+.
> 
>> I think i read somewhere that at least Pascal could do some deep color
>> output over HDMI as well, which makes sense for HDMI-based HDR-10 support.
> 
> I believe Kepler+ devices (and perhaps GF119 as well) should support
> higher bpc over HDMI. However there's no support for that in nouveau
> right now. I happen to have a monitor (TV) that advertises 12bpc
> support, so I may play with it.
> 
> Here's how dithering is controlled:
> 
> https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml#L435
> 
> (and also exposed in the public display class docs at
> http://download.nvidia.com/open-gpu-doc/Display-Class-Methods/2/ )
> 
> In theory turning off dithering should also flip off that ENABLE bit,
> but perhaps we messed something up. Or HDMI is extra-special and
> doesn't respect that bit and always has it enabled.
> 
>    -ilia
> 
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Nouveau Digest, Vol 131, Issue 3

[Ilia Mirkin]

On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner
<mario.kleiner.de@gmail.com> wrote:
> On 03/03/2018 12:59 AM, Ilia Mirkin wrote:
>>
>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
>> <mario.kleiner.de@gmail.com> wrote:
>>>
>>> On 03/02/2018 11:29 PM, Ilia Mirkin wrote:
>>>>
>>>> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set
>>>> still only gets called with a 256-entry LUT? If so, that works nicely
>>>> here, but is not intuitive :)
>>>
>>>
>>> Yes. Lots of remapping in the server, i get dizzy everytime i look at it,
>>> and forget almost immediately how stuff fits together when i don't look
>>> at
>>> it. Anyway, the final downsampling from 1024 -> 256 hw lut happens in
>>> xf86RandR12CrtcComputeGamma(), see
>>>
>>>
>>> https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5f9fcd50a999a00128c0cc3f6e7d1f66182c9d5
>>>
>>> for the latest. I'll propose that one to get cherry-picked into the
>>> server-1.19 branch as well.
>>
>>
>> Hrmph. That means we should try to adjust the gamma_set helper to do
>> the sampling when receiving a 1024-sized LUT, if people will use older
>> X servers (seems likely). Should hopefully be straightforward, to
>> handle just that one case.
>
>
> I think we never receive anything but a 256 slot LUT via gamma_set afaics?
> The server initializes xf86Crtc's gamma_size to 256 at startup, and none of
> the ddx'es ever overrides that with actual info from the kernel.
>
> What happens on older servers without that patch iff color depth 30 is
> selected is simply that the gamma table updates no-op, so the server runs
> with an identity gamma table setup at startup. Not perfect, but also not
> that bad, given that probably most people run their setups with a gamma of
> 1.0 anyway. At default depth 24 stuff works as usual.

Ah OK. That's not so bad. I'll try to play around with it this week.
Thanks for the explanation!

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Nouveau Digest, Vol 131, Issue 3

[Ilia Mirkin]

On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner
> <mario.kleiner.de@gmail.com> wrote:
>> On 03/03/2018 12:59 AM, Ilia Mirkin wrote:
>>>
>>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
>>> <mario.kleiner.de@gmail.com> wrote:
>>>>
>>>> On 03/02/2018 11:29 PM, Ilia Mirkin wrote:
>>>>>
>>>>> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set
>>>>> still only gets called with a 256-entry LUT? If so, that works nicely
>>>>> here, but is not intuitive :)
>>>>
>>>>
>>>> Yes. Lots of remapping in the server, i get dizzy everytime i look at it,
>>>> and forget almost immediately how stuff fits together when i don't look
>>>> at
>>>> it. Anyway, the final downsampling from 1024 -> 256 hw lut happens in
>>>> xf86RandR12CrtcComputeGamma(), see
>>>>
>>>>
>>>> https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5f9fcd50a999a00128c0cc3f6e7d1f66182c9d5
>>>>
>>>> for the latest. I'll propose that one to get cherry-picked into the
>>>> server-1.19 branch as well.
>>>
>>>
>>> Hrmph. That means we should try to adjust the gamma_set helper to do
>>> the sampling when receiving a 1024-sized LUT, if people will use older
>>> X servers (seems likely). Should hopefully be straightforward, to
>>> handle just that one case.
>>
>>
>> I think we never receive anything but a 256 slot LUT via gamma_set afaics?
>> The server initializes xf86Crtc's gamma_size to 256 at startup, and none of
>> the ddx'es ever overrides that with actual info from the kernel.
>>
>> What happens on older servers without that patch iff color depth 30 is
>> selected is simply that the gamma table updates no-op, so the server runs
>> with an identity gamma table setup at startup. Not perfect, but also not
>> that bad, given that probably most people run their setups with a gamma of
>> 1.0 anyway. At default depth 24 stuff works as usual.
>
> Ah OK. That's not so bad. I'll try to play around with it this week.
> Thanks for the explanation!

I just tested this out against xorg 1.19.5. With your patch, I get an
extremely dark screen. I think it's just getting the first 256 of the
1024 values (I checked -- gamma_set is still only getting 256 values).
So we have to do something a bit cleverer to fix this scenario...
ideas?

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Nouveau Digest, Vol 131, Issue 3

[Ilia Mirkin]

On Thu, Mar 8, 2018 at 11:29 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner
>> <mario.kleiner.de@gmail.com> wrote:
>>> On 03/03/2018 12:59 AM, Ilia Mirkin wrote:
>>>>
>>>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
>>>> <mario.kleiner.de@gmail.com> wrote:
>>>>>
>>>>> On 03/02/2018 11:29 PM, Ilia Mirkin wrote:
>>>>>>
>>>>>> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set
>>>>>> still only gets called with a 256-entry LUT? If so, that works nicely
>>>>>> here, but is not intuitive :)
>>>>>
>>>>>
>>>>> Yes. Lots of remapping in the server, i get dizzy everytime i look at it,
>>>>> and forget almost immediately how stuff fits together when i don't look
>>>>> at
>>>>> it. Anyway, the final downsampling from 1024 -> 256 hw lut happens in
>>>>> xf86RandR12CrtcComputeGamma(), see
>>>>>
>>>>>
>>>>> https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5f9fcd50a999a00128c0cc3f6e7d1f66182c9d5
>>>>>
>>>>> for the latest. I'll propose that one to get cherry-picked into the
>>>>> server-1.19 branch as well.
>>>>
>>>>
>>>> Hrmph. That means we should try to adjust the gamma_set helper to do
>>>> the sampling when receiving a 1024-sized LUT, if people will use older
>>>> X servers (seems likely). Should hopefully be straightforward, to
>>>> handle just that one case.
>>>
>>>
>>> I think we never receive anything but a 256 slot LUT via gamma_set afaics?
>>> The server initializes xf86Crtc's gamma_size to 256 at startup, and none of
>>> the ddx'es ever overrides that with actual info from the kernel.
>>>
>>> What happens on older servers without that patch iff color depth 30 is
>>> selected is simply that the gamma table updates no-op, so the server runs
>>> with an identity gamma table setup at startup. Not perfect, but also not
>>> that bad, given that probably most people run their setups with a gamma of
>>> 1.0 anyway. At default depth 24 stuff works as usual.
>>
>> Ah OK. That's not so bad. I'll try to play around with it this week.
>> Thanks for the explanation!
>
> I just tested this out against xorg 1.19.5. With your patch, I get an
> extremely dark screen. I think it's just getting the first 256 of the
> 1024 values (I checked -- gamma_set is still only getting 256 values).
> So we have to do something a bit cleverer to fix this scenario...
> ideas?

Mario,

Have you given this any thought? Is there a way to detect one or the
other scenario? I'd rather not put something in where we check the X
version at compile time. Did the ABI get bumped in 1.20 perhaps?

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Nouveau Digest, Vol 131, Issue 3

[Mario Kleiner]

On Sat, Apr 28, 2018 at 7:22 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> On Thu, Mar 8, 2018 at 11:29 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>> On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>>> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner
>>> <mario.kleiner.de@gmail.com> wrote:
>>>> On 03/03/2018 12:59 AM, Ilia Mirkin wrote:
>>>>>
>>>>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
>>>>> <mario.kleiner.de@gmail.com> wrote:
>>>>>>
>>>>>> On 03/02/2018 11:29 PM, Ilia Mirkin wrote:
>>>>>>>
>>>>>>> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set
>>>>>>> still only gets called with a 256-entry LUT? If so, that works nicely
>>>>>>> here, but is not intuitive :)
>>>>>>
>>>>>>
>>>>>> Yes. Lots of remapping in the server, i get dizzy everytime i look at it,
>>>>>> and forget almost immediately how stuff fits together when i don't look
>>>>>> at
>>>>>> it. Anyway, the final downsampling from 1024 -> 256 hw lut happens in
>>>>>> xf86RandR12CrtcComputeGamma(), see
>>>>>>
>>>>>>
>>>>>> https://cgit.freedesktop.org/xorg/xserver/commit/?id=b5f9fcd50a999a00128c0cc3f6e7d1f66182c9d5
>>>>>>
>>>>>> for the latest. I'll propose that one to get cherry-picked into the
>>>>>> server-1.19 branch as well.
>>>>>
>>>>>
>>>>> Hrmph. That means we should try to adjust the gamma_set helper to do
>>>>> the sampling when receiving a 1024-sized LUT, if people will use older
>>>>> X servers (seems likely). Should hopefully be straightforward, to
>>>>> handle just that one case.
>>>>
>>>>
>>>> I think we never receive anything but a 256 slot LUT via gamma_set afaics?
>>>> The server initializes xf86Crtc's gamma_size to 256 at startup, and none of
>>>> the ddx'es ever overrides that with actual info from the kernel.
>>>>
>>>> What happens on older servers without that patch iff color depth 30 is
>>>> selected is simply that the gamma table updates no-op, so the server runs
>>>> with an identity gamma table setup at startup. Not perfect, but also not
>>>> that bad, given that probably most people run their setups with a gamma of
>>>> 1.0 anyway. At default depth 24 stuff works as usual.
>>>
>>> Ah OK. That's not so bad. I'll try to play around with it this week.
>>> Thanks for the explanation!
>>
>> I just tested this out against xorg 1.19.5. With your patch, I get an
>> extremely dark screen. I think it's just getting the first 256 of the
>> 1024 values (I checked -- gamma_set is still only getting 256 values).
>> So we have to do something a bit cleverer to fix this scenario...
>> ideas?
>
> Mario,
>
> Have you given this any thought? Is there a way to detect one or the
> other scenario? I'd rather not put something in where we check the X
> version at compile time. Did the ABI get bumped in 1.20 perhaps?
>
>   -ilia

Nope, haven't had time to retest on 1.19, too much "fun" trying to
tame all those new server 1.20 bugs which got in the way of depth 30
stuff.
I think the video ABI got bumped in 1.20.

-mario
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau