From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
Cc: "mesa-dev-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<mesa-dev-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x
Date: Fri, 4 Sep 2015 15:10:31 +0200 [thread overview]
Message-ID: <55E99847.70707@redhat.com> (raw)
In-Reply-To: <CAKb7UvjSMb_c8yYwERbmN0Gkk9DkcmtetRAakZXg16PRtwt7KQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On 03-09-15 19:32, Ilia Mirkin wrote:
> On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdegoede@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 <hdegoede@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
next prev parent reply other threads:[~2015-09-04 13:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-03 11:25 [PATCH mesa 0/4] nv30: Various fixes Hans de Goede
[not found] ` <1441279509-7147-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-03 11:25 ` [PATCH mesa 1/4] nv30: Fix creation of scanout buffers Hans de Goede
2015-09-03 17:23 ` [Nouveau] " Ilia Mirkin
2015-09-03 11:25 ` [PATCH mesa 2/4] nv30: Implement color resolve for msaa Hans de Goede
[not found] ` <1441279509-7147-3-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-03 17:29 ` Ilia Mirkin
2015-09-03 11:25 ` [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x Hans de Goede
[not found] ` <1441279509-7147-4-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-03 17:32 ` Ilia Mirkin
[not found] ` <CAKb7UvjSMb_c8yYwERbmN0Gkk9DkcmtetRAakZXg16PRtwt7KQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-04 13:10 ` Hans de Goede [this message]
[not found] ` <55E99847.70707-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-04 17:09 ` Ilia Mirkin
2015-09-03 11:25 ` [PATCH mesa 4/4] nv30: Disable msaa on nv4x because it causes gpu lockups Hans de Goede
[not found] ` <1441279509-7147-5-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-09-03 17:33 ` Ilia Mirkin
[not found] ` <CAKb7Uvhh3rcLa2f4vMi19=SagnKtQhh+wzJYrZALA2EF5o8V2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-04 13:14 ` Hans de Goede
2015-09-03 17:14 ` [PATCH mesa 0/4] nv30: Various fixes Ilia Mirkin
2015-09-04 12:44 ` [Nouveau] " Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55E99847.70707@redhat.com \
--to=hdegoede-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org \
--cc=mesa-dev-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.