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 tt
The sifm object has a limit of 1024x1024 for its input size and 2048x2048
for its output. The code checking this was trying to be clever resulting
in it seeing a surface of e.g 1024x256 being outside of the input size
limit.
This commit fixes this.
Signed-off-by: Hans de Goede
---
src/gallium/d
We do not have a generic blitter on nv3x cards, so we must use the
sifm object for color resolving.
This commit divides the sources and dest surfaces in to tiles which
match the constraints of the sifm object, so that color resolving
will work properly on nv3x cards.
Signed-off-by: Hans de Goede
Yeah, I noticed this was odd too when looking over the code earlier.
Glad you picked up on that as well.
Reviewed-by: Ilia Mirkin
Cc: "10.6 11.0"
On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede wrote:
> The sifm object has a limit of 1024x1024 for its input size and 2048x2048
> for its output. T
May I ask why you're doing 512x512 instead of 1024x1024? These are
already scaled up coordinates, so 1024x1024 should work no? Or is it
because of the seams on the edges? Do those not also appear with
512x512 or does it sample outside of the box?
Separately, why not use this approach on nv40 as we
On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede 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]] vali
https://bugs.freedesktop.org/show_bug.cgi?id=31139
Pierre Moreau changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
