Hi,
On 03-09-15 19:32, Ilia Mirkin wrote:
On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdego...@redhat.com> wrote:
On nv3x we will likely end up using the cpu to do color resolving for msaa
blits. Disable msaa on these cards so that we do not end up using the cpu.
Actually the CPU fallback won't do scaled, so it's stuck with SIFM or
assert(false). Which isn't great, but... it's what the HW does.
Ok.
I don't see a reason to shut that off. I'd rather disallow allocating MS
surfaces that SIFM won't later be able to resolve on nv3x.
Hmm, my first hunch when reading this was: "that is not going to work,
apps pick a visual and then alloc surfaces for that visual and only
that visual, they will not fall back to another visual if the alloc
fails."
Still I've given this a try, resulting in this:
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
index 76bb8b8..172ffc1 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c
@@ -325,6 +325,7 @@ nv30_miptree_create(struct pipe_screen *pscreen,
const struct pipe_resource *tmpl)
{
struct nouveau_device *dev = nouveau_screen(pscreen)->device;
+ struct nv30_screen *screen = nv30_screen(pscreen);
struct nv30_miptree *mt = CALLOC_STRUCT(nv30_miptree);
struct pipe_resource *pt = &mt->base.base;
unsigned blocksz, size;
@@ -356,6 +357,15 @@ nv30_miptree_create(struct pipe_screen *pscreen,
w = pt->width0 << mt->ms_x;
h = pt->height0 << mt->ms_y;
+
+ /* On nv3x ms requires sifm, make sure we meet the sifm constraints */
+ if (screen->eng3d->oclass < NV40_3D_CLASS && tmpl->nr_samples > 0 &&
+ ((w | h) > 1024 || w < 2 || h < 2)) {
+ debug_printf("refusing to create ms buffer with a size of %dx%d\n", w,
h);
+ FREE(mt);
+ return NULL;
+ }
+
d = (pt->target == PIPE_TEXTURE_3D) ? pt->depth0 : 1;
blocksz = util_format_get_blocksize(pt->format);
But as I guessed already this does not make impress happy, it still tries
to use a ms visuals, and then hobbles along showing an uninitialized
frontbuffer, as it was doing before the patch to implement color
resolve.
I've checked and the debug printf I added works, so either I'm doing this
at the wrong place, or this is just not a good idea.
BTW there are more arguments to disable msaa on nv3x:
1) nv3x is slow enough without it
2) nv3x cards typically only have 64M of memory and msaa
takes a significant amount of extra memory.
Regards,
Hans
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 7aad26b..69acc38 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -319,8 +319,16 @@ nv30_screen_is_format_supported(struct pipe_screen
*pscreen,
unsigned sample_count,
unsigned bindings)
{
- if (sample_count > 4)
- return false;
+ struct nv30_screen *screen = nv30_screen(pscreen);
+
+ if (screen->eng3d->oclass >= NV40_3D_CLASS) {
+ if (sample_count > 4)
+ return false;
+ } else {
+ if (sample_count > 0)
+ return false;
+ }
+
if (!(0x00000017 & (1 << sample_count)))
return false;
--
2.4.3
_______________________________________________
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
