[Nouveau] [PATCH] nv50, nvc0: flush texture cache in presence of coherent bufs
This fixes the newly-added arb_texture_buffer_object-bufferstorage
piglit test.
Signed-off-by: Ilia Mirkin
Cc: "11.0"
---
src/gallium/drivers/nouveau/nv50/nv50_vbo.c | 19 +++
src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c | 20
2 files changed, 39 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
b/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
index e798473..f5f4708 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
@@ -768,6 +768,7 @@ nv50_draw_vbo(struct pipe_context *pipe, const struct
pipe_draw_info *info)
{
struct nv50_context *nv50 = nv50_context(pipe);
struct nouveau_pushbuf *push = nv50->base.pushbuf;
+ bool tex_dirty = false;
int i, s;
/* NOTE: caller must ensure that (min_index + index_bias) is >= 0 */
@@ -797,6 +798,9 @@ nv50_draw_vbo(struct pipe_context *pipe, const struct
pipe_draw_info *info)
push->kick_notify = nv50_draw_vbo_kick_notify;
+ /* TODO: Instead of iterating over all the buffer resources looking for
+* coherent buffers, keep track of a context-wide count.
+*/
for (s = 0; s < 3 && !nv50->cb_dirty; ++s) {
uint32_t valid = nv50->constbuf_valid[s];
@@ -824,6 +828,21 @@ nv50_draw_vbo(struct pipe_context *pipe, const struct
pipe_draw_info *info)
nv50->cb_dirty = false;
}
+ for (s = 0; s < 3 && !tex_dirty; ++s) {
+ for (i = 0; i < nv50->num_textures[s] && !tex_dirty; ++i) {
+ if (!nv50->textures[s][i] ||
+ nv50->textures[s][i]->texture->target != PIPE_BUFFER)
+continue;
+ if (nv50->textures[s][i]->texture->flags &
+ PIPE_RESOURCE_FLAG_MAP_COHERENT)
+tex_dirty = true;
+ }
+ }
+ if (tex_dirty) {
+ BEGIN_NV04(push, NV50_3D(TEX_CACHE_CTL), 1);
+ PUSH_DATA (push, 0x20);
+ }
+
if (nv50->vbo_fifo) {
nv50_push_vbo(nv50, info);
push->kick_notify = nv50_default_kick_notify;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
index 6f9e790..188c7d7 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
@@ -899,6 +899,9 @@ nvc0_draw_vbo(struct pipe_context *pipe, const struct
pipe_draw_info *info)
push->kick_notify = nvc0_draw_vbo_kick_notify;
+ /* TODO: Instead of iterating over all the buffer resources looking for
+* coherent buffers, keep track of a context-wide count.
+*/
for (s = 0; s < 5 && !nvc0->cb_dirty; ++s) {
uint32_t valid = nvc0->constbuf_valid[s];
@@ -924,6 +927,23 @@ nvc0_draw_vbo(struct pipe_context *pipe, const struct
pipe_draw_info *info)
nvc0->cb_dirty = false;
}
+ for (s = 0; s < 5; ++s) {
+ for (int i = 0; i < nvc0->num_textures[s]; ++i) {
+ struct nv50_tic_entry *tic = nv50_tic_entry(nvc0->textures[s][i]);
+ struct pipe_resource *res;
+ if (!tic)
+continue;
+ res = nvc0->textures[s][i]->texture;
+ if (res->target != PIPE_BUFFER ||
+ !(res->flags & PIPE_RESOURCE_FLAG_MAP_COHERENT))
+continue;
+
+ BEGIN_NVC0(push, NVC0_3D(TEX_CACHE_CTL), 1);
+ PUSH_DATA (push, (tic->id << 4) | 1);
+ NOUVEAU_DRV_STAT(&nvc0->screen->base, tex_cache_flush_count, 1);
+ }
+ }
+
if (nvc0->state.vbo_mode) {
nvc0_push_vbo(nvc0, info);
push->kick_notify = nvc0_default_kick_notify;
--
2.4.6
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v3] pci: Handle 5-bit and 8-bit tag field
If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
number of outstanding requests, so cap it to 32 if extended tag is unsupported.
Fixes: fdo#86537
v2: Restrict changes to chipsets >= 0x84
v3:
* Add nvkm_pci_mask to pci.h
* Mask bit 8 before setting it
Signed-off-by: Pierre Moreau
---
drm/nouveau/include/nvkm/subdev/pci.h | 1 +
drm/nouveau/nvkm/subdev/pci/base.c| 25 +
2 files changed, 26 insertions(+)
diff --git a/drm/nouveau/include/nvkm/subdev/pci.h
b/drm/nouveau/include/nvkm/subdev/pci.h
index 5b3c054..774ca66 100644
--- a/drm/nouveau/include/nvkm/subdev/pci.h
+++ b/drm/nouveau/include/nvkm/subdev/pci.h
@@ -24,6 +24,7 @@ struct nvkm_pci {
u32 nvkm_pci_rd32(struct nvkm_pci *, u16 addr);
void nvkm_pci_wr08(struct nvkm_pci *, u16 addr, u8 data);
void nvkm_pci_wr32(struct nvkm_pci *, u16 addr, u32 data);
+u32 nvkm_pci_mask(struct nvkm_pci *, u16 addr, u32 mask, u32 add);
void nvkm_pci_rom_shadow(struct nvkm_pci *, bool shadow);
int nv04_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
diff --git a/drm/nouveau/nvkm/subdev/pci/base.c
b/drm/nouveau/nvkm/subdev/pci/base.c
index d1c148e..cb2835b 100644
--- a/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drm/nouveau/nvkm/subdev/pci/base.c
@@ -46,6 +46,14 @@ nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32 data)
pci->func->wr32(pci, addr, data);
}
+u32
+nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32 add)
+{
+ u32 data = pci->func->rd32(pci, addr);
+ pci->func->wr32(pci, addr, (data & ~mask) | add);
+ return data;
+}
+
void
nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow)
{
@@ -115,6 +123,23 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
if (ret)
return ret;
+ if (pci_is_pcie(pdev) && subdev->device->chipset >= 0x84) {
+ /* Tag field is 8-bit long, regardless of EXT_TAG.
+* However, if EXT_TAG is disabled, only the lower 5 bits of
the tag
+* field should be used, limiting the number of request to 32.
+*
+* Apparently, 0x041c stores some limit on the number of
requests
+* possible, so if EXT_TAG is disabled, limit that requests
number to
+* 32
+*
+* Fixes fdo#86537
+*/
+ if (nvkm_pci_rd32(pci, 0x007c) & 0x0020)
+ nvkm_pci_mask(pci, 0x0080, 0x0100, 0x0100);
+ else
+ nvkm_pci_mask(pci, 0x041c, 0x0060, 0x);
+ }
+
pci->irq = pdev->irq;
return ret;
}
--
2.5.2
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2] pci: Handle 5-bit and 8-bit tag field
On Wed, Sep 16, 2015 at 3:52 PM, Pierre Moreau wrote:
> If the hardware supports extended tag field (8-bit ones), then enabled it.
> This
> is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
> In case extended tag field is not supported, 5-bit tag field is used which
> limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
> number of outstanding requests, so cap it to 32 if extended tag is
> unsupported.
>
> Fixes: fdo#86537
>
> v2: Restrict changes to chipsets >= 0x84
>
> Signed-off-by: Pierre Moreau
> ---
> drm/nouveau/nvkm/subdev/pci/base.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drm/nouveau/nvkm/subdev/pci/base.c
> b/drm/nouveau/nvkm/subdev/pci/base.c
> index d1c148e..bbad29d 100644
> --- a/drm/nouveau/nvkm/subdev/pci/base.c
> +++ b/drm/nouveau/nvkm/subdev/pci/base.c
> @@ -46,6 +46,14 @@ nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32 data)
> pci->func->wr32(pci, addr, data);
> }
>
> +u32
> +nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32 add)
Either add this to the header or make it static. I have a mild
preference for the latter.
> +{
> + u32 data = pci->func->rd32(pci, addr);
> + pci->func->wr32(pci, addr, (data & ~mask) | add);
> + return data;
> +}
> +
> void
> nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow)
> {
> @@ -115,6 +123,23 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
> if (ret)
> return ret;
>
> + if (pci_is_pcie(pdev) && subdev->device->chipset >= 0x84) {
> + /* Tag field is 8-bit long, regardless of EXT_TAG.
> +* However, if EXT_TAG is disabled, only the lower 5 bits of
> the tag
> +* field should be used, limiting the number of request to 32.
> +*
> +* Apparently, 0x041c stores some limit on the number of
> requests
> +* possible, so if EXT_TAG is disabled, limit that requests
> number to
> +* 32
> +*
> +* Fixes fdo#86537
> +*/
> + if (nvkm_pci_rd32(pci, 0x007c) & 0x0020)
> + nvkm_pci_mask(pci, 0x0080, 0x, 0x0100);
Normally this is done as 0x100, 0x100, although your way works.
However a future change might mask out any unwanted bits from the
value as well...
> + else
> + nvkm_pci_mask(pci, 0x041c, 0x0060, 0x);
> + }
> +
> pci->irq = pdev->irq;
> return ret;
> }
> --
> 2.5.2
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v2] pci: Handle 5-bit and 8-bit tag field
If the hardware supports extended tag field (8-bit ones), then enabled it. This
is usually done by the VBIOS, but not on some MBPs (see fdo#86537).
In case extended tag field is not supported, 5-bit tag field is used which
limits the possible values to 32. Apparently bits 7:0 of 0x8841c stores some
number of outstanding requests, so cap it to 32 if extended tag is unsupported.
Fixes: fdo#86537
v2: Restrict changes to chipsets >= 0x84
Signed-off-by: Pierre Moreau
---
drm/nouveau/nvkm/subdev/pci/base.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drm/nouveau/nvkm/subdev/pci/base.c
b/drm/nouveau/nvkm/subdev/pci/base.c
index d1c148e..bbad29d 100644
--- a/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drm/nouveau/nvkm/subdev/pci/base.c
@@ -46,6 +46,14 @@ nvkm_pci_wr32(struct nvkm_pci *pci, u16 addr, u32 data)
pci->func->wr32(pci, addr, data);
}
+u32
+nvkm_pci_mask(struct nvkm_pci *pci, u16 addr, u32 mask, u32 add)
+{
+ u32 data = pci->func->rd32(pci, addr);
+ pci->func->wr32(pci, addr, (data & ~mask) | add);
+ return data;
+}
+
void
nvkm_pci_rom_shadow(struct nvkm_pci *pci, bool shadow)
{
@@ -115,6 +123,23 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
if (ret)
return ret;
+ if (pci_is_pcie(pdev) && subdev->device->chipset >= 0x84) {
+ /* Tag field is 8-bit long, regardless of EXT_TAG.
+* However, if EXT_TAG is disabled, only the lower 5 bits of
the tag
+* field should be used, limiting the number of request to 32.
+*
+* Apparently, 0x041c stores some limit on the number of
requests
+* possible, so if EXT_TAG is disabled, limit that requests
number to
+* 32
+*
+* Fixes fdo#86537
+*/
+ if (nvkm_pci_rd32(pci, 0x007c) & 0x0020)
+ nvkm_pci_mask(pci, 0x0080, 0x, 0x0100);
+ else
+ nvkm_pci_mask(pci, 0x041c, 0x0060, 0x);
+ }
+
pci->irq = pdev->irq;
return ret;
}
--
2.5.2
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] gm204/6: add voltage control using the new gk104 volt class
I got confirmation that we can read and change the voltage with the same code.
The divider is also computed correctly on the gm204 we got our hands on.
Thanks to Yoshimo on IRC for executing the tests on his gm204!
Signed-off-by: Martin Peres
---
drm/nouveau/nvkm/engine/device/base.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drm/nouveau/nvkm/engine/device/base.c
b/drm/nouveau/nvkm/engine/device/base.c
index b324fd1..8e9b5e8 100644
--- a/drm/nouveau/nvkm/engine/device/base.c
+++ b/drm/nouveau/nvkm/engine/device/base.c
@@ -1982,6 +1982,7 @@ nv124_chipset = {
.pci = nv40_pci_new,
.pmu = gm107_pmu_new,
.timer = gk20a_timer_new,
+ .volt = gk104_volt_new,
.ce[0] = gm204_ce_new,
.ce[1] = gm204_ce_new,
.ce[2] = gm204_ce_new,
@@ -2012,6 +2013,7 @@ nv126_chipset = {
.pci = nv40_pci_new,
.pmu = gm107_pmu_new,
.timer = gk20a_timer_new,
+ .volt = gk104_volt_new,
.ce[0] = gm204_ce_new,
.ce[1] = gm204_ce_new,
.ce[2] = gm204_ce_new,
--
2.5.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v2] nv50, nvc0: detect underlying resource changes and update tic
When updating texture buffers, we might end up replacing the whole
buffer. Check that the tic address matches the resource address, and if
not, update the tic and reupload it.
This fixes:
arb_direct_state_access-texture-buffer
arb_texture_buffer_object-data-sync
Signed-off-by: Ilia Mirkin
Cc: "11.0"
---
This seems like a better version of the previous attempt to fix this,
since it no longer relies on the sampler view being bound. And it
keeps the tic update logic along with the other tic logic.
src/gallium/drivers/nouveau/nv50/nv50_tex.c | 18 ++
src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 19 +++
2 files changed, 37 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
index fc6374d..70f8928 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
@@ -221,6 +221,23 @@ nv50_create_texture_view(struct pipe_context *pipe,
return &view->pipe;
}
+static void
+nv50_update_tic(struct nv50_context *nv50, struct nv50_tic_entry *tic,
+struct nv04_resource *res)
+{
+ if (res->base.target != PIPE_BUFFER)
+ return;
+ if (tic->tic[1] == (uint32_t)res->address &&
+ (tic->tic[2] & 0xff) == res->address >> 32)
+ return;
+
+ nv50_screen_tic_unlock(nv50->screen, tic);
+ tic->id = -1;
+ tic->tic[1] = res->address;
+ tic->tic[2] &= 0xff00;
+ tic->tic[2] |= res->address >> 32;
+}
+
static bool
nv50_validate_tic(struct nv50_context *nv50, int s)
{
@@ -240,6 +257,7 @@ nv50_validate_tic(struct nv50_context *nv50, int s)
continue;
}
res = &nv50_miptree(tic->pipe.texture)->base;
+ nv50_update_tic(nv50, tic, res);
if (tic->id < 0) {
tic->id = nv50_screen_tic_alloc(nv50->screen, tic);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
index d19082e..0174407 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c
@@ -226,6 +226,23 @@ nvc0_create_texture_view(struct pipe_context *pipe,
return &view->pipe;
}
+static void
+nvc0_update_tic(struct nvc0_context *nvc0, struct nv50_tic_entry *tic,
+struct nv04_resource *res)
+{
+ if (res->base.target != PIPE_BUFFER)
+ return;
+ if (tic->tic[1] == (uint32_t)res->address &&
+ (tic->tic[2] & 0xff) == res->address >> 32)
+ return;
+
+ nvc0_screen_tic_unlock(nvc0->screen, tic);
+ tic->id = -1;
+ tic->tic[1] = res->address;
+ tic->tic[2] &= 0xff00;
+ tic->tic[2] |= res->address >> 32;
+}
+
static bool
nvc0_validate_tic(struct nvc0_context *nvc0, int s)
{
@@ -247,6 +264,7 @@ nvc0_validate_tic(struct nvc0_context *nvc0, int s)
continue;
}
res = nv04_resource(tic->pipe.texture);
+ nvc0_update_tic(nvc0, tic, res);
if (tic->id < 0) {
tic->id = nvc0_screen_tic_alloc(nvc0->screen, tic);
@@ -313,6 +331,7 @@ nve4_validate_tic(struct nvc0_context *nvc0, unsigned s)
continue;
}
res = nv04_resource(tic->pipe.texture);
+ nvc0_update_tic(nvc0, tic, res);
if (tic->id < 0) {
tic->id = nvc0_screen_tic_alloc(nvc0->screen, tic);
--
2.4.6
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] External monitor remains black - nouveau reports "link training failed"
On Wed, Sep 16, 2015 at 1:14 PM, Fredy Neeser wrote: > > Hello list, > > I had a working dual-monitor setup with KDE Plasma 5 on a Lenovo W530 > "Optimus" laptop (hybrid graphics, nouveau + i915 drivers), but it seems to > fall apart with recent kernels, i.e., the external monitor (connected to > the laptop's docking station via DisplayPort) no longer works. > > My setup still works fine with kernels up to and including > 4.1.3-201.fc22.x86_64, but with kernel 4.1.6-200.fc22 (as well as > another update on top of 4.1.6), the external monitor remains black, and > the journal shows several lines > > kernel: nouveau E[ PDISP][:01:00.0][0x0006] 06:0006:0f48: > link training failed > > not present with previous kernels -- see also > > https://bugzilla.redhat.com/show_bug.cgi?id=1260053 > Bug 1260053 - External monitor remains black with kernel > 4.1.6-200.fc22.x86_64 - nouveau reports "link training failed" > > > Could this be related to some changes in powering down the DPs (which > requires link training to resume)? > > Any ideas for debugging / narrowing down the issue are much appreciated ! Looking at the nouveau changes between v4.1.3 and v4.1.6 -- nothing looks particularly relevant. You could try reverting stable tree commit 140d4baa12 (commit 697bb728d9 upstream) but if that's the cause, then I'll be quite surprised. Can you see if perhaps Redhat added some additional custom patches in the 4.1.6 builds? Not sure where they list that stuff, and am not particularly inclined to search myself. If manually looking at these things doesn't reveal anything, doing a bisect is going to be your best bet. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] External monitor remains black - nouveau reports "link training failed"
Hello list, I had a working dual-monitor setup with KDE Plasma 5 on a Lenovo W530 "Optimus" laptop (hybrid graphics, nouveau + i915 drivers), but it seems to fall apart with recent kernels, i.e., the external monitor (connected to the laptop's docking station via DisplayPort) no longer works. My setup still works fine with kernels up to and including 4.1.3-201.fc22.x86_64, but with kernel 4.1.6-200.fc22 (as well as another update on top of 4.1.6), the external monitor remains black, and the journal shows several lines kernel: nouveau E[ PDISP][:01:00.0][0x0006] 06:0006:0f48: link training failed not present with previous kernels -- see also https://bugzilla.redhat.com/show_bug.cgi?id=1260053 Bug 1260053 - External monitor remains black with kernel 4.1.6-200.fc22.x86_64 - nouveau reports "link training failed" Could this be related to some changes in powering down the DPs (which requires link training to resume)? Any ideas for debugging / narrowing down the issue are much appreciated ! Fredy Neeser IBM Zurich Research Laboratory Switzerland ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 71357] [NVC1] After S3 resume X is broken and reboot needed
https://bugs.freedesktop.org/show_bug.cgi?id=71357 --- Comment #10 from Torsten Krah --- Hi, i did what you've suggested and used 4.3.0-040300rc1-generic #201509160642 SMP build from ubuntu mainline ppa. And i am really happy - did S3 twice and all works fine, its waking up and works - i can even do S3 twice, resume and it works. Even KernelModeSetting on console does work flawlessly now where 3.13 did work and 3.16 did not with my external monitors, thumbs up - seems fixed with 4.3-rc1. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91310] witcher 2 glitches a lot
https://bugs.freedesktop.org/show_bug.cgi?id=91310 --- Comment #3 from Karol Herbst --- seems like the issue gets worse the lower the core clock is, for reasons I don't understand -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89969] nouveau: add support for chunk decoding in order to support vaapi (st/va)
https://bugs.freedesktop.org/show_bug.cgi?id=89969 --- Comment #30 from Julien Isorce --- Patches have been sent to mailing list for review. vc1, mpeg12, mpeg4 are working but not h264 (visible but lot of blockiness) Need someone to try existing st/va with a radeon card and using: LIBVA_DRIVER_NAME=gallium mpv --hwdec=vaapi anyH264Video.mp4 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89969] nouveau: add support for chunk decoding in order to support vaapi (st/va)
https://bugs.freedesktop.org/show_bug.cgi?id=89969 Julien Isorce changed: What|Removed |Added Attachment #117932|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89969] nouveau: add support for chunk decoding in order to support vaapi (st/va)
https://bugs.freedesktop.org/show_bug.cgi?id=89969 Julien Isorce changed: What|Removed |Added Attachment #117931|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89969] nouveau: add support for chunk decoding in order to support vaapi (st/va)
https://bugs.freedesktop.org/show_bug.cgi?id=89969 Julien Isorce changed: What|Removed |Added Attachment #117929|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89969] nouveau: add support for chunk decoding in order to support vaapi (st/va)
https://bugs.freedesktop.org/show_bug.cgi?id=89969 Julien Isorce changed: What|Removed |Added Attachment #117939|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89969] nouveau: add support for chunk decoding in order to support vaapi (st/va)
https://bugs.freedesktop.org/show_bug.cgi?id=89969 Julien Isorce changed: What|Removed |Added Attachment #117936|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89969] nouveau: add support for chunk decoding in order to support vaapi (st/va)
https://bugs.freedesktop.org/show_bug.cgi?id=89969 Julien Isorce changed: What|Removed |Added Attachment #117937|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89969] nouveau: add support for chunk decoding in order to support vaapi (st/va)
https://bugs.freedesktop.org/show_bug.cgi?id=89969 Julien Isorce changed: What|Removed |Added Attachment #117934|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89969] nouveau: add support for chunk decoding in order to support vaapi (st/va)
https://bugs.freedesktop.org/show_bug.cgi?id=89969 Julien Isorce changed: What|Removed |Added Attachment #117938|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89969] nouveau: add support for chunk decoding in order to support vaapi (st/va)
https://bugs.freedesktop.org/show_bug.cgi?id=89969 Julien Isorce changed: What|Removed |Added Attachment #117930|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89969] nouveau: add support for chunk decoding in order to support vaapi (st/va)
https://bugs.freedesktop.org/show_bug.cgi?id=89969 Julien Isorce changed: What|Removed |Added Attachment #117928|0 |1 is obsolete|| -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 92013] [NVA0] 4.3-rc1 fan set to full speed after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=92013 --- Comment #1 from Ilia Mirkin --- Wow that's a monster commit. Which also happens to change the semantics of a *whole lot* of stuff. Unfortunately this will have to wait for Ben to take a look. In the meanwhile, would you mind posting a dmesg when the kernel is booted with nouveau.debug=debug from both right before and at this commit? Should hopefully show what's going wrong. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
