search for: bpc

..._mode *mode = &asyh->state.adjusted_mode; + unsigned int max_rate, mode_rate; + + switch (nv_encoder->dcb->type) { + case DCB_OUTPUT_DP: + max_rate = nv_encoder->dp.link_nr * nv_encoder->dp.link_bw; + + /* we don't support more than 10 anyway */ + asyh->or.bpc = max_t(u8, asyh->or.bpc, 10); + + /* reduce the bpc until it works out */ + while (asyh->or.bpc > 6) { + mode_rate = DIV_ROUND_UP(mode->clock * asyh->or.bpc * 3, 8); + if (mode_rate <= max_rate) + break; + + asyh->or.bpc -= 2; + } + break; + default: + break; + }...

Realized when I moved nouveau over to using the atomic DP MST VCPI helpers that I forgot to ensure that we clamp the BPC to 8 to make us less likely to run out of bandwidth on a topology when enabling multiple displays that support >8 BPC - something we want to do until we have support for dynamically selecting the bpc based on the topology's available bandwidth, since userspace isn't really using HDR yet...

On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote: > On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul <lyude at redhat.com> wrote: > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > > > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > > > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? > > > > I don't think that display_info.bpc actually implies a minimum bpc, only a > > maximum bpc iirc (Ville would know the answer to...

In order to be able to use bpc values that are different from what the connector reports, we want to be able to store the bpc value we decide on using for an atomic state in nv50_head_atom and refer to that instead of simply using the value that the connector reports throughout the whole atomic check phase and commit phase. This...

On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? I don't think that display_info.bpc actually implies a minimum bpc, only a maximum bpc iirc (Ville would know the answer to this one). The other thing to note here...

This just limits the BPC for MST connectors to a maximum of 8 from nv50_mstc_get_modes(), instead of doing so during nv50_msto_atomic_check(). This doesn't introduce any functional changes yet (other then userspace now lying about the max bpc, but we can't support that yet anyway so meh). But, we'll need this i...

...y did reject modes like I expected during testing), Ville Syrjala from Intel pointed out that the logic here isn't correct. max_clock refers to the max symbol rate supported by the encoder, so limiting clock to ds_clock using max() doesn't make sense. Additionally, we want to check against 6bpc for the time being since that's the minimum possible bpc here, not the reported bpc from the connector. See: https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html For more info. So, let's rewrite this using Ville's advice. Signed-off-by: Lyude Paul <lyude at...

...Lyude Paul <lyude at redhat.com> wrote: > > On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote: > > On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul <lyude at redhat.com> wrote: > > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > > > > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > > > > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? > > > > > > I don't think that display_info.bpc actually implies a minimum bpc, only a > > > maximum bpc iirc (Ville would...

Noticed this while working on some unrelated CRC stuff. Currently, userspace has very little support for BPCs higher than 8. While this doesn't matter for most things, on MST topologies we need to be careful about ensuring that we do our best to make any given display configuration fit within the bandwidth restraints of the topology, since otherwise less people's monitor configurations will work....

...cted during testing), Ville Syrjala from Intel pointed out > > that the logic here isn't correct. max_clock refers to the max symbol > > rate supported by the encoder, so limiting clock to ds_clock using max() > > doesn't make sense. Additionally, we want to check against 6bpc for the > > time being since that's the minimum possible bpc here, not the reported > > bpc from the connector. See: > > > > https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html > > > > For more info. > > > > So, let'...

On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul <lyude at redhat.com> wrote: > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? > > I don't think that display_info.bpc actually implies a minimum bpc, only a > maximum bpc iirc (Ville would know the answer to this one). The other...

...ved. 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 >>...

...gt; like I expected during testing), Ville Syrjala from Intel pointed out > that the logic here isn't correct. max_clock refers to the max symbol > rate supported by the encoder, so limiting clock to ds_clock using max() > doesn't make sense. Additionally, we want to check against 6bpc for the > time being since that's the minimum possible bpc here, not the reported > bpc from the connector. See: > > https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html > > For more info. > > So, let's rewrite this using Ville's advice....

...etect on MST connectors completely for free. Lyude Paul (5): drm/nouveau/kms/nv50-: Initialize core channel in nouveau_display_create() drm/nouveau/kms/nv50-: Probe SOR caps for DP interlacing support drm/nouveau/kms/gv100-: Add support for interlaced modes drm/nouveau/kms/nv50-: Move 8BPC limit for MST into nv50_mstc_get_modes() drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST drivers/gpu/drm/nouveau/dispnv50/core.h | 3 ++ drivers/gpu/drm/nouveau/dispnv50/core507d.c | 15 ++++++ drivers/gpu/drm/nouveau/dispnv50/core827d.c | 1 + drivers/gpu/drm/nouve...

Hello, I try to run an sqareparts-catalog from Federal Mogul under Wine. Installation works, but it wont run... some ideas? Code: jeanfelix at Soloma-G6:~$ env WINEPREFIX="/home/jeanfelix/.wine" wine C:\\windows\\command\\start.exe /Unix /home/jeanfelix/.wine/dosdevices/c:/users/Public/Bureau/XCD11.lnk fixme:exec:SHELL_execute flags ignored: 0x00000100 fixme:exec:SHELL_execute flags

...000fed94000 (reserved) > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > (XEN) 0000000100000000 - 000000011ee00000 (usable) > (XEN) ACPI: RSDP 000F9810, 0024 (r2 HPQOEM) > (XEN) ACPI: XSDT D8A2C088, 0094 (r1 HPQOEM SLIC-BPC 1072009 AMI 10013) > (XEN) ACPI: FACP D8A36650, 010C (r5 HPQOEM SLIC-BPC 1072009 AMI 10013) > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is longer than ACPI > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > (XEN) ACPI: DSDT D8A2C1B0, A49B (r2 HPQOEM SLIC-BPC...

...ting), Ville Syrjala from Intel pointed out > > > that the logic here isn't correct. max_clock refers to the max symbol > > > rate supported by the encoder, so limiting clock to ds_clock using max() > > > doesn't make sense. Additionally, we want to check against 6bpc for the > > > time being since that's the minimum possible bpc here, not the reported > > > bpc from the connector. See: > > > > > > https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html > > > > > > For more info. &gt...

...@@ -771,16 +771,20 @@ nv50_msto_atomic_check(struct drm_encoder *encoder, struct nv50_head_atom *asyh = nv50_head_atom(crtc_state); int slots; - /* When restoring duplicated states, we need to make sure that the - * bw remains the same and avoid recalculating it, as the connector's - * bpc may have changed after the state was duplicated - */ - if (!state->duplicated) - asyh->dp.pbn = - drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock, - connector->display_info.bpc * 3); + if (crtc_state->mode_changed || crtc_state->connectors_changed) { + /* + *...

...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. v2: Also deal with X-Server 1.19 and earlier, which as of v1.19.6 lack a fix to color palette handling and can not deal with depths/bpc > 24/8 bpc. On < 1.20 we skip xf86HandleColormaps() setup at > 8 bpc. This disables color palette handling on such servers at > 8 bpc, but still keeps RandR gamma table handling intact. Tested on 1.19.6 and 1.20.0 to do the right thing. Signed-off-by: Mario Kleiner &lt...

...connectors completely for free. Lyude Paul (5): drm/nouveau/kms/nv50-: Initialize core channel in nouveau_display_create() drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support drm/nouveau/kms/gv100-: Add support for interlaced modes drm/nouveau/kms/nv50-: Move 8BPC limit for MST into nv50_mstc_get_modes() drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST drivers/gpu/drm/nouveau/dispnv50/core.h | 7 +++ drivers/gpu/drm/nouveau/dispnv50/core507d.c | 15 ++++++ drivers/gpu/drm/nouveau/dispnv50/core827d.c | 1 + drivers/gpu/drm/nouv...