similar to: [PATCH] nv30/nv40 Gallium drivers unification

This patchset applies some minor fixes to renouveau.xml and then unifies the nv30 and nv40 register definitions. nv30 and nv40 are very similar and have the same offsets for the registers they share. The major differences are: 1. Texture setup is different due to full NPOT support on nv40 2. More advanced blending/render targets on nv40 3. NV30 has fixed function registers, which NV40 lacks The

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

This patch series silences some unknown cap warnings and fixes up coding style (patch 1+4). The most important part of this series are the two patches in the middle. They rework the state_fb code, so that we are able to render to not 64 byte aligned targets, as this is the only real use-case for render temporaries this allows us to drop temp code completely and simplifies a lot

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:

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

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

NV10TCL defines the vertex buffer registers both as arrays and as individual named registers. This causes duplicate register definitions and the individual registers are not used either by the DDX or by the Mesa driver. Francisco Jerez said to remove them all. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- renouveau.xml | 49

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]:

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

https://bugs.freedesktop.org/show_bug.cgi?id=56757 Priority: medium Bug ID: 56757 Assignee: nouveau at lists.freedesktop.org Summary: [regression][bisected][screenshots] nvfx -> nv30 driver rework causes regression in UrbanTerror4.2 (beta5) Severity: normal Classification: Unclassified

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

Hi All, I wanted to understand the type unification algorithm (the implementations of 'refineAbstractTypeTo') used in LLVM. In the source code, there are a lot of code relevant to 'refineAbstractTypeTo', and I didn't find a big picture about how it works. Does the code implement any standard type unification algorithm that I can refer to? What is a good start point to

Currently on NV30/NV40 an assert will be triggered once 32 queries are outstanding. This violates the OpenGL/Gallium interface, which requires support for an unlimited number of fences. This patch fixes the problem by putting queries in a linked list and waiting on the oldest one if allocation fails. nVidia seems to use a similar strategy, but with 1024 instead of 32 fences. The next patch will

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

For all these patches I'd say: testers are welcome. The first three patches seem good enough to push as we speak IMHO (so if you agree, go ahead!), whereas for the fourth I don't know if this is the desired way to fix. The result of these four patches is that NV34 gives a nearly-correct desktop experience, where only some fading animations appear broken. It's quite useable now! [1/4]:

fixes these warnings: nvfx_screen_get_param:95 - Warning: unknown PIPE_CAP 30 nvfx_screen_get_param:95 - Warning: unknown PIPE_CAP 55 nvfx_screen_get_param:95 - Warning: unknown PIPE_CAP 56 nvfx_screen_get_param:95 - Warning: unknown PIPE_CAP 58 nvfx_screen_get_param:95 - Warning: unknown PIPE_CAP 59 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47442 Bugzilla:

I am trying to understand the s3tc init code as nv50 gallium has a problem with that. It looks like some drivers (r300g and llvmpipe) actually inits s3tc in two places : ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() Here is an extract of the backtrace calls while loading fgfs on llvmpipe : driCreateScreen ->

Currently on NV30/NV40 an assert will be triggered once 32 queries are outstanding. This violates the OpenGL/Gallium interface, which requires support for an unlimited number of fences. This patch fixes the problem by putting queries in a linked list and waiting on the oldest one if allocation fails. nVidia seems to use a similar strategy, but with 1024 instead of 32 fences. The next patch will

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

Celestia 1.6.0 again shows corrupted rendering on planets, other parts rendered correctly with the latest git pull on the nvfx-next-5 tree. Yesterday's nvfx-next tree worked perfectly. -- http://www.munted.org.uk One very high maintenance cat living here.