search for: nv30_miptree_cr

...>>>> >>>> I discussed this with Ben this morning and he suggested that this >>>> is likely a Mesa issue since with DRI3 mesa rather then the ddx >>>> allocs the surfaces. I've tried disabling swizzling in the >>>> mesa code by forcing nv30_miptree_create() to always take >>>> the code path for linear textures, but that leads to the exact >>>> same result as before that change. >>> >>> >>> Ah yes. Very different problem indeed. I actually suspect it has to do >>> with swizzling. Look at...

...leading to >> software rendering. >> >> I discussed this with Ben this morning and he suggested that this >> is likely a Mesa issue since with DRI3 mesa rather then the ddx >> allocs the surfaces. I've tried disabling swizzling in the >> mesa code by forcing nv30_miptree_create() to always take >> the code path for linear textures, but that leads to the exact >> same result as before that change. > > Ah yes. Very different problem indeed. I actually suspect it has to do > with swizzling. Look at the white pattern of the moon -- it's all in a &...

...with them > expecting different llvm versions. > > I've done some further debugging adding some debug printf-s to the > texture creation paths for nv3x, this bit is interesting, glretrace > does: > > nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0 > nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1 > target 2 > > So it gets a texture from a handle, which I believe is the child-window > in which the animation will be shown, and then create another texture > with the same dimensions to serve as back buffer I presume. > &gt...

On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher at gmail.com> wrote: > On Thu, Aug 27, 2015 at 1:55 PM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> On 27-08-15 15:46, Marek Olšák wrote: >>> >>> On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede <hdegoede at redhat.com> >>> wrote: >>>>

...gt;> >>> I've done some further debugging adding some debug printf-s to the >>> texture creation paths for nv3x, this bit is interesting, glretrace >>> does: >>> >>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0 >>> nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1 >>> target 2 >>> >>> So it gets a texture from a handle, which I believe is the child-window >>> in which the animation will be shown, and then create another texture >>> with the same dimensions to...

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

...but that seems to also automatically disable all DRI, leading to software rendering. I discussed this with Ben this morning and he suggested that this is likely a Mesa issue since with DRI3 mesa rather then the ddx allocs the surfaces. I've tried disabling swizzling in the mesa code by forcing nv30_miptree_create() to always take the code path for linear textures, but that leads to the exact same result as before that change. Regards, Hans

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

...& NOUVEAU_TEXTURE_USAGE_LINEAR) { tx->direct = true; diff --git a/src/gallium/drivers/nv30/nv30_miptree.c b/src/gallium/drivers/nv30/nv30_miptree.c index 8fbba38..c4838f2 100644 --- a/src/gallium/drivers/nv30/nv30_miptree.c +++ b/src/gallium/drivers/nv30/nv30_miptree.c @@ -65,6 +65,9 @@ nv30_miptree_create(struct pipe_screen *pscreen, const struct pipe_texture *pt) struct nv30_miptree *mt; unsigned buf_usage = PIPE_BUFFER_USAGE_PIXEL | NOUVEAU_BUFFER_USAGE_TEXTURE; + static int no_swizzle = -1; + if(no_swizzle < 0) + no_swizzle = debug_get_bool_option("NOUVEAU_...

Hi Maarten, xf86-video-nouveau causes a garbled display when running gnome-shell on nv4x (tested with nv43 and nv46) since this commit: http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e7289f25a342a457952b9b0e539c2f0b81d99 I've seen some discussion about issues caused by enabling dri, but AFAIK no solution let. I have time to help with debugging / fixing this, but I

...eight0, l), 64); - else - offset += nv30mt->level[l].pitch * u_minify(pt->height0, l); - } - - nv30mt->level[l].image_offset[f] = offset; - offset += nv30mt->level[l].pitch * u_minify(pt->height0, l); - } - - nv30mt->total_size = offset; -} - -static struct pipe_texture * -nv30_miptree_create(struct pipe_screen *pscreen, const struct pipe_texture *pt) -{ - struct nv30_miptree *mt; - unsigned buf_usage = PIPE_BUFFER_USAGE_PIXEL | - NOUVEAU_BUFFER_USAGE_TEXTURE; - - mt = MALLOC(sizeof(struct nv30_miptree)); - if (!mt) - return NULL; - mt->base = *pt; - pipe_re...

...eight0, l), 64); - else - offset += nv30mt->level[l].pitch * u_minify(pt->height0, l); - } - - nv30mt->level[l].image_offset[f] = offset; - offset += nv30mt->level[l].pitch * u_minify(pt->height0, l); - } - - nv30mt->total_size = offset; -} - -static struct pipe_texture * -nv30_miptree_create(struct pipe_screen *pscreen, const struct pipe_texture *pt) -{ - struct nv30_miptree *mt; - unsigned buf_usage = PIPE_BUFFER_USAGE_PIXEL | - NOUVEAU_BUFFER_USAGE_TEXTURE; - - mt = MALLOC(sizeof(struct nv30_miptree)); - if (!mt) - return NULL; - mt->base = *pt; - pipe_re...