similar to: [Patches]mesa/nv30: Diverse set of patches that improve NV3x render quality

A reworked version of 3 out of 4 patches mentioned earlier. [1/4]: Fixes nearly all piglit vertprog testcases, due to now being able to pass the results on to the fragment shader. V2: rename samplers to texcoords. [2/4]: Fixes shader compiler assertion errors, as some source registers do not exist for certain operations. Fixes several piglit tests when mesa is compiled with --enable-debug [3/4]:

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Perhaps there was a day when those were different, but that day is not today. src/gallium/drivers/nouveau/nv30/nv30_context.c | 1 - src/gallium/drivers/nouveau/nv30/nv30_context.h | 1 - src/gallium/drivers/nouveau/nv30/nvfx_fragprog.c | 20 ++++++++++---------- src/gallium/drivers/nouveau/nv30/nvfx_vertprog.c | 8 ++++---- 4

On 26.05.2015 02:49, Ilia Mirkin wrote: > On Mon, May 25, 2015 at 8:37 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> >> On 25.05.2015 21:29, Ilia Mirkin wrote: >>> Commit 8acaf862dfe switched things over to use TEXCOORD instead of >>> GENERIC, but did not update the nv30 swtnl draw paths. This teaches the >>> draw

On 25.05.2015 21:29, Ilia Mirkin wrote: > Commit 8acaf862dfe switched things over to use TEXCOORD instead of > GENERIC, but did not update the nv30 swtnl draw paths. This teaches the > draw logic about TEXCOORD. > > Among other things, this fixes a crash in demos/arbocclude when using > swtnl. Curiously enough, the point-sprite piglit works without this. > > Signed-off-by:

This makes the vertex buffer go to GART, not VRAM, and redoes the mapping to not use the UNSYNCHRONIZED access (which is meaningless on a VRAM buffer anyways). While we're at it, add some flushes for VBO data. Moving the vertex buffer from VRAM to GART makes glxgears work fully with NV30_SWTNL=1. The other changes just seem like a good idea. I'm not sure *why* moving the buffer from VRAM

On 05/24/2015 06:58 AM, Ilia Mirkin wrote: > 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 <imirkin at alum.mit.edu> > --- > src/gallium/drivers/nouveau/nv30/nv30_state_validate.c | 16

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 clearing. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> ---

> On 24 May 2015, at 16:03, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > > On 24.05.2015 10:38, Samuel Pitoiset wrote: >> >> >> On 05/24/2015 06:58 AM, Ilia Mirkin wrote: >>> nv30_validate_clip depends on the rasterizer state. Also we should >>> upload all the new clip planes on change since next time the

On Sun, May 24, 2015 at 10:56 AM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > On 24.05.2015 16:15, Pierre Moreau wrote: >>> >>> On 24 May 2015, at 16:03, Tobias Klausmann >>> <tobias.johannes.klausmann at mni.thm.de> wrote: >>> >>> >>> >>> On 24.05.2015 10:38, Samuel Pitoiset wrote:

On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdegoede at 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. I

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 <hdegoede at redhat.com> --- Changes in v2: -Use 1024x1024 blocks -Use the sifm on both nv3x

First some data errors I get with both nv20 exa and nv20 dri/mesa. 1. RT_FORMAT LINEAR + X8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x00000105 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x00000105 LINEAR + A8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x00000108 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x00000108 The only value I found in renouveau dump

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4 +-

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 6 ++++++ src/gallium/drivers/nouveau/nv30/nvfx_fragprog.c | 1 + 2 files changed, 7 insertions(+) diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index

https://bugs.freedesktop.org/show_bug.cgi?id=73358 Priority: medium Bug ID: 73358 Assignee: nouveau at lists.freedesktop.org Summary: [nv34] adobe flash + firefox -> DATA_ERROR QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: ronald645 at gmail.com

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4

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 <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/nv30/nv30_transfer.c | 4 ++-- 1 file changed, 2

Hi All, Here is a bunch of fixes for nv30 cards, the first patch is a resend of a patch I send a while back. AFAICT that one is ready for merging, but it is not entirely clear to me what the process is for getting (nouveau) mesa patches merged. Should I request commit rights, and push my own patches once they have been reviewed ? Regards, Hans

It should be possible to make this be 16 on nvc0. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Not touching nv50 since I have a patch that actually impelents support for multiple viewports there. src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 ++ 2 files changed, 4 insertions(+) diff --git

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 well? I can't imagine the blitter would be faster... does this result in lower quality? On