similar to: [PATCH] gallium/nouveau: use pre-calculated stride for resource_get_handle

This patch rewrites all the miptree layout and transfer code in the pre-NV50 Gallium drivers. The code is also unified among them and put in the nv04 directory. The current code is broken in several ways: 1. 3D textures are laid out first by face, then by level, which is incorrect 2. Cube maps should have 128-byte aligned faces 3. Swizzled textures have a strange alignment test that seems

Changes: - Fixed some nv##_miptree that were not converted to nv04_miptree. - Disable swizzling on non-RGBA 2D textures, since the current 2D code is mostly broken in those cases. A later patch will fix this. Thanks to Andrew Randrianasulu who reported this. This patch rewrites all the miptree layout and transfer code in the pre-NV50 Gallium drivers. The code is also unified among them and

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

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

This patch fixes two issues in nv40_miptree_layout. First, pt->width0 is used, which is the size of the whole texture, while width, which is the size of the mipmap level, should be used. Second, the current code does not 64-byte align the pitch of swizzled textures. However, on my NV40 this causes a pgraph error regarding the pitch register (and sometimes a system lockup too), which is fixed

Hi, On 03-08-15 20:09, Ilia Mirkin wrote: > On Mon, Aug 3, 2015 at 1:31 PM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> >> On 03-08-15 17:36, Ilia Mirkin wrote: >>> >>> On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede <hdegoede at redhat.com> wrote: >>>> >>>> Hi, >>>> >>>> On

Hi, On 03-08-15 17:36, Ilia Mirkin wrote: > On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> On 30-07-15 16:09, Ilia Mirkin wrote: >>> >>> FWIW this is a fail on nv50+ as well. See for example >>> https://bugs.freedesktop.org/show_bug.cgi?id=91445 >>> >>> My suspicion is that this is

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

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

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

Currently we are continuously spewing messages messages about these variables since we call debug_get_bool_option everytime we want to check their value This is annoying, slows things down due to terminal rerendering and obscures useful messages. This patch only calls debug_get_bool_option once and caches the result in a static variable. --- src/gallium/drivers/nv04/nv04_transfer.c | 6 ++++--

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 33 +++++++++++++------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index 4baabaf..5c3d783 100644 --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c +++

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

Fixed. Thanks. Evan On Feb 11, 2008, at 2:35 AM, Duncan Sands wrote: > I'm seeing the following failures with "make check" (x86-32 linux): > > FAIL: test/CodeGen/X86/fold-mul-lohi.ll > Failed with exit(1) at line 2 > while running: llvm-as < test/CodeGen/X86/fold-mul-lohi.ll | llc - > march=x86-64 | not grep lea > leaq B, %rsi > leaq

I'm seeing the following failures with "make check" (x86-32 linux): FAIL: test/CodeGen/X86/fold-mul-lohi.ll Failed with exit(1) at line 2 while running: llvm-as < test/CodeGen/X86/fold-mul-lohi.ll | llc -march=x86-64 | not grep lea leaq B, %rsi leaq A, %r8 leaq P, %rsi child process exited abnormally FAIL:

Fixed. However, I wonder if we are doing the right / smart codegen for static codegen. AMD64 ABI document seems to indicate rip relative addressing should be used even in this case (see page 38). You know about about Linux addressing mode than I do. Please check. Thanks, Evan On Feb 12, 2008, at 10:10 AM, Dan Gohman wrote: > Hi Evan, > > In -relocation-model=static mode, those

Hi Evan, In -relocation-model=static mode, those tests are now getting code like this leaq A, %rsi movss %xmm0, (%rsi,%rdx,4) instead of this: movss %xmm0, A(,%rdx,4) This is specifically what these tests were written to catch :-). Running them with -relocation-model=pic is hiding the real bug. Dan On Feb 11, 2008, at 11:22 PM, Evan Cheng wrote: > Fixed.

We enable compression only for some supported formats Suggested-by: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 23 +++++++++++++++++++++-- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 7 +++++++ 2 files changed, 28 insertions(+), 2 deletions(-) diff --git

We enable compression only for some supported formats Suggested-by: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 4 ++-- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 11 +++++++++-- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git

Hi, Is mke2fs' stride option relevant for a multi-striped LVM volume? Cheers, Stephen