similar to: [PATCH] nouveau: fix glCompressedTexImage

On Sun, Sep 14, 2014 at 3:37 AM, Francisco Jerez <currojerez at riseup.net> wrote: > Ilia Mirkin <imirkin at alum.mit.edu> writes: > >> mesa_texstore expects pixel data, not compressed data. For compressed >> textures, we want to just copy the bits in without any conversion. >> > > Any reason we cannot use _mesa_store_compressed_*image for this instead

Ilia Mirkin <imirkin at alum.mit.edu> writes: > mesa_texstore expects pixel data, not compressed data. For compressed > textures, we want to just copy the bits in without any conversion. > Any reason we cannot use _mesa_store_compressed_*image for this instead of rolling our own? > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- >

--- Hi, this is still WIP, but already passes piglit's s3tc-teximage, s3tc-texsubimage and fbo-generatemipmap-formats(s3tc tests) and even Wolfenstein:Enemy-Territory works on my nv25. It's based on Ben's newlib branch. I have few issues though: 1) So far it needs libtxc_dxtn, but I might expose the s3tc extensions even without encoder using driconf option - Is that desirable? 2)

This fixes issues where get_rt_format would see a 0 format because the nouveau_surface had not been properly initialized. Fixes crash on supertuxkart startup (which still fails due to out-of-vram issues). Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/mesa/drivers/dri/nouveau/nouveau_texture.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git

Fixes mipmap generation. Signed-off-by: Viktor Novotn? <noviktor at seznam.cz> --- Hi, this fixes bug with mipmaps I observed on nv25, where in _mesa_prepare_mipmap_level call to Driver.FreeTextureImageBuffer unreferences nouveau_teximage's nouveau_surface, which then doesnt get reallocated in Driver.AllocTextureImageBuffer, because vieux uses swrast implementation, ultimately leading

Fixes assertions when trying to attach textures to fbs with formats not supported by the render engines. See https://bugs.freedesktop.org/show_bug.cgi?id=73459 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- In a perfect world I'd have separate callbacks for depth and color, but given the list of supported values, I don't think this matters. Also I used

ioemu: fix xenfb slow case update Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r 067d8f19e78a tools/ioemu/hw/xenfb.c --- a/tools/ioemu/hw/xenfb.c Thu Feb 28 13:55:37 2008 +0000 +++ b/tools/ioemu/hw/xenfb.c Fri Feb 29 15:25:17 2008 +0000 @@ -1072,7 +1072,7 @@ /* A convenient function for munging pixels between different depths */ #define

Hello, The following two patches add an additional offset part in the FB resize event. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

ARB_sampler_object is very simple software only extension to support. I want to make it mandator extension for Mesa drivers to allow meta module to use it. This patch add support for the extension to nouveau. It is completely untested search and replace patch. I hope someone with old NV hardware could give a try that there is no regressions and ARB_sampler_object tests passes. Signed-off-by:

Fixes assertions when trying to attach textures to fbs with formats not supported by the render engines. See https://bugs.freedesktop.org/show_bug.cgi?id=73459 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Francisco, thanks for the review. Is this more like what you had in mind? Interesting that nv10/nv20 support different-bitness color/depth -- that requirement came back for

Attached is a .ll with a reproducible test case for the bug addressed by r100044 -- "Fix a nasty dangling-pointer heisenbug that could generate wrong code pretty much anywhere AFAICT." Doing llvm-as < sunkaddr.ll | llc which a llc after r100044 will generate .LBB1_2: # %if-false-block movl $1, 16(%rdi) movl 120(%rdi), %eax

Ilia Mirkin <imirkin at alum.mit.edu> writes: > Fixes assertions when trying to attach textures to fbs with formats not > supported by the render engines. > > See https://bugs.freedesktop.org/show_bug.cgi?id=73459 > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- Hi Ilia, > > In a perfect world I'd have separate callbacks for depth and

https://bugs.freedesktop.org/show_bug.cgi?id=101335 Bug ID: 101335 Summary: build failure: nouveau_screen.c:105:8: error: implicit declaration of function ‘nouveau_drm_new’; Product: Mesa Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority:

The following series of 10 patches is a merge of the xenfb and xenconsoled functionality into the qemu-dm code. The general approach taken is to have qemu-dm provide two machine types - one for xen paravirt, the other for fullyvirt. For compatability the later is the default. The goals overall are to kill LibVNCServer, remove alot of code duplication and/or parallel impls of the same concepts, and

I have recently been trying to build rgl on MacOS X 10.4 using R-2.1.1 with gcc-4.0 5026 and gfortran. The R binary I built without problems and it includes libpng and Tcl/ Tk on X11. Rcmdr works correctly. The rgl build produces a large number of warnings like: g++ -no-cpp-precomp -I/Library/Frameworks/R.framework/Resources/ include -I/System/Library/Frameworks/OpenGL.framework/Headers

For a long time the gallium pipe drivers for nvidia fixed function cards (nv0x, nv1x and, to some extent, nv2x) have remained unmaintained and godforsaken -- especially nv0x and nv1x had seen almost no progress since their creation. They've recently grown a classic mesa driver which implements many new features: texturing, hardware-accelerated tnl. However the killer feature is "it