similar to: [PATCH] Fix glTexSubImage on swizzled surfaces on <=NV40

https://bugs.freedesktop.org/show_bug.cgi?id=110500 Bug ID: 110500 Summary: X-Server crashes - GL error: GL_OUT_OF_MEMORY in glTexSubImage Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium

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

13:28 < pmdata> ymanton> We have a bit more work to do for 8 bits texture. 13:28 < pmdata> Swizzling works by halving dimensions, and using a8r8g8b8 as format as seen in dumps for test_texture_format. 13:28 < pmdata> I nearly got text in progs/demos/texenv: http://people.freedesktop.org/~pmandin/20091011.png 13:28 < pmdata> My current

On Fr, 2014-09-12 at 10:10 +0100, Stefan Hajnoczi wrote: > On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote: > > diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt > > new file mode 100644 > > index 0000000..9455383 > > --- /dev/null > > +++ b/docs/specs/virtio-gpu.txt > > @@ -0,0 +1,165 @@ > > +virtio-gpu specification >

On Sun, Jan 25, 2009 at 10:58 AM, Jimmy Rentz <jedynamic at bellsouth.net> wrote: > Hello, > I was playing around with the OpenGlSuperBible samples and > noticed some odd issues around textures. Yes, I know it won't > be perfect right now (and not supported)...I am just curious > if you see the same issues. > Well, I am seeing some

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

Hello, I have been looking at cubic texture mapping for a bit, and I have found that hw mipmap generation doesn't work at all or the textures are all messed up (normal 2d work fine). This is with linear textures. Also of note is that software mipmap generation works fine. I have done sanity checks for the miptree pitches, offsets, etc and everything seems to match up fine for both the

Bonjour. (1) Is there any other open source GPU backend in LLVM? (2) I'd like to know the current status and plan of NV40 LLVM backend. Does it work? I cloned from git://anongit.freedesktop.org/~marcheu/llvm, but it seems that a lot of code are stilling missing. I've done a search on Nouveau wiki and mailing list but what I only found is: "Marcheu is working on and off on LLVM for

ThibG from irc reported an issue with transparent cursors, i noticed the ddx had a workaround, which wasn't in the kms code. ThibG (whoever you are), please test. The patch is untested. Maarten. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-nv04-import-hw-workaround-for-partially-transparent-.patch Type: text/x-patch Size: 4908 bytes Desc: not

--- src/gallium/drivers/nv40/nv40_fragprog.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/nv40/nv40_fragprog.c b/src/gallium/drivers/nv40/nv40_fragprog.c index 1237066..209d211 100644 --- a/src/gallium/drivers/nv40/nv40_fragprog.c +++ b/src/gallium/drivers/nv40/nv40_fragprog.c @@ -843,7 +843,8 @@ nv40_fragprog_translate(struct nv40_context *nv40,

In a message to the Nouveau mailing list (http://lists.freedesktop.org/archives/nouveau/2009-January/002166.html), you said that you cloned the git tree of Stephane Marchesin's NV40 LLVM work, at git://anongit.freedesktop.org/~marcheu/llvm That code has since been lost due to an hard drive crash. If you happened to still have that git tree on your hard drive, it would be extremely appreciated

On the Radeon IRC channel (http://www.radeonhd.org/?page=archive_display&c=radeon&m=1&y=2009&d=2009-1-26), you expressed interest in Corbin Simpson's R300 LLVM work, at git://anongit.freedesktop.org/~csimpson/llvm, which was based on Stephane Marchesin's earlier NV40 work. Both these projects have since been lost due to an hard drive crash. If you happened to still have

https://bugs.freedesktop.org/show_bug.cgi?id=56721 Tollef Fog Heen <tfheen at err.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|sitewranglers at lists.freedes |nouveau at lists.freedesktop.o |ktop.org |rg QA Contact|

Hi Nouveau enthusiasts, One week ago was merged the thermal/fan management code for most nvidia cards. So far, no major issue arose but we would like to have more testing as soon as possible to deliver a nice and solid support when Linux 3.8 is released. Thermal management is split into two parts: - Temperature monitoring: Making sure your card doesn't overheat - Fan management: Driving

https://bugs.freedesktop.org/show_bug.cgi?id=56721 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Nouveau driver fails on |[NV4A] Nouveau driver fails |nv40 with error -12 (out of |on nv40 with error -12 (out

https://bugs.freedesktop.org/show_bug.cgi?id=56721 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Ilia Mirkin <imirkin at

Hi Ben, Pre-nv40 cards don't have domains defined, which the nouveau_clock_init code assumes exists. The following (white-space-damaged, sorry) patch fixes boot for me, haven't really tested the pre-nv40 cards in my system much further. I assume there's some proper fix here. -ilia diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c

The problem affects nv40 cards during booting. It comes from there being two places where subdev arrays are maintained. A commit was recently added to make the two equal. However, the struct nouveau_device version ends up being referenced before it is initialized. The problem arises during the creation of the INSTMEM and THERM subdevs. ' Signed off by: Bob Gleitsmann rjgleits at bellsouth.net

https://bugs.freedesktop.org/show_bug.cgi?id=87641 Bug ID: 87641 Summary: Oops in 3.19.0-rc1 - nv40 and older - patch included Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Driver/nouveau Assignee: