Hi,
On 07-09-15 22:00, Ilia Mirkin wrote:
On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede <hdego...@redhat.com> wrote:
msaa use on nv30 may trigger a (mesa?) bug where dmesg says:
[ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list
[ 1197.850654] nouveau E[soffice.bin[3785]] validate: -12
[ 1201.766955] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1201.766961] nouveau E[soffice.bin[3785]] validating bo list
[ 1201.766968] nouveau E[soffice.bin[3785]] validate: -12
After which the program using the msaa visual freezes, and eventually
the entire system freezes. Disable msaa until this is fixed.
This happens on both nv3x and nv4x cards.
Ugh. This is aka "you ran out of vram, goodbye".
Ah right 12 == ENOMEM. This also explains why I can reproduce this much
easier on a 64 MB nv34 card then on my nv46 card which has more RAM.
We don't really
handle that case extremely well. I feel really bad doing this :( The
issue is anachronistic applications like soffice that don't keep with
the limitations of GPUs of the days of yore. So we end up penalizing
people who do use applications of the day.
But the practical issue is that people do upgrade, and people do run
these applications, and so it makes sense to keep it off by default.
Could I convince you to use debug_get_int_option (or something along
those lines, forget the function name) to still allow an env var
override? Like NV30_MAX_MSAA or something (and clamp it to 4 so people
don't get ideas).
Using debug_get_int_option and defaulting it to 0 sounds like a good
idea, I'll do a v2 using this, and I'll update the comment / commit
message to reflect that this is caused by the applications causing
us to go oom.
Regards,
Hans
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
