On Thu, May 21, 2015 at 11:32 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, May 21, 2015 at 10:05 AM, Robert Morell rmor...@nvidia.com wrote:
Hi Ilia,
On Sat, May 02, 2015 at 12:34:21PM -0400, Ilia Mirkin wrote:
Hi,
As I'm looking to add some support to nouveau for features like
Reviewed-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de
On 23.05.2015 18:56, Ilia Mirkin wrote:
There can be scenarios where the indirect arg of a PFETCH becomes
known, and so the code will attempt to propagate it. Use this
opportunity to just fold it into the first argument, and
On Fri, May 22, 2015 at 3:23 AM, Martin Peres martin.pe...@free.fr wrote:
On 21/05/2015 11:47, Ben Skeggs wrote:
On 21 May 2015 at 16:08, Alexandre Courbot acour...@nvidia.com wrote:
Add a flag allowing Nouveau to specify that an object should be coherent
at allocation time. This is required
Hello Tobias,
Reply inline.
--- original message ---
From: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de
Date: 01:00:17 23-05-2015
To: Roy Spliet rspl...@eclipso.eu, nouveau@lists.freedesktop.org
Subject: Re: [Nouveau] [PATCH 4/9] nvkm/fb/ramnv50: Ressurect timing code, use
proper
There can be scenarios where the indirect arg of a PFETCH becomes
known, and so the code will attempt to propagate it. Use this
opportunity to just fold it into the first argument, and prevent the
load propagation pass from touching PFETCH further.
This fixes
Like on GT215
Signed-off-by: Roy Spliet rspl...@eclipso.eu
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv50.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv50.c
This difference can of course be negative too...
Signed-off-by: Roy Spliet rspl...@eclipso.eu
---
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
Signed-off-by: Roy Spliet rspl...@eclipso.eu
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c
index 47d53ed..bc36a4f
Some of the bits in there are similar to the bits in the gt215 rammap.
Signed-off-by: Roy Spliet rspl...@eclipso.eu
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/ramcfg.h | 5 +
drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/rammap.h | 2 ++
In preparation of NV50 reclocking, where there is no version
Signed-off-by: Roy Spliet rspl...@eclipso.eu
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/ramcfg.h | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/bios/rammap.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
V2:
- Slightly clarify the conditional timings in nv50_ram_timing_calc()
- now rated U, approved for general audiences
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Might need some generalisation to GT200. For those: use at your own risk!
Signed-off-by: Roy Spliet rspl...@eclipso.eu
---
.../drm/nouveau/include/nvkm/subdev/bios/ramcfg.h | 16 ++
.../drm/nouveau/include/nvkm/subdev/bios/rammap.h | 2 +
drivers/gpu/drm/nouveau/nvkm/subdev/bios/rammap.c
On Thu, May 21, 2015 at 5:35 PM, Ben Skeggs skeg...@gmail.com wrote:
On 21 May 2015 at 16:04, Alexandre Courbot gnu...@gmail.com wrote:
On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs skeg...@gmail.com wrote:
On 21 May 2015 at 15:49, Alexandre Courbot gnu...@gmail.com wrote:
On Thu, May 21, 2015
On 23.05.2015 08:06, Ilia Mirkin wrote:
There can be scenarios where the indirect arg of a PFETCH becomes
known, and so the code will attempt to propagate it. Use this
opportunity to just fold it into the first argument, and prevent the
load propagation pass from touching PFETCH further.
This
There can be scenarios where the indirect arg of a PFETCH becomes
known, and so the code will attempt to propagate it. Use this
opportunity to just fold it into the first argument, and prevent the
load propagation pass from touching PFETCH further.
This fixes
Clearing can happen at a time when various state objects are incoherent
and not ready for a draw. Some of the validation functions don't handle
this well, so only flush the framebuffer state. This has the advantage
of also not doing extra work.
This works around some crashes that can happen when
nv30_validate_clip depends on the rasterizer state. Also we should
upload all the new clip planes on change since next time the plane data
won't have changed, but the enables might.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nv30/nv30_state_validate.c | 16
17 matches
Mail list logo
