similar to: [Bug 50280] New: Mesa 8.0.3 fails to build dri/nouveau against libdrm 2.4.34

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

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

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

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

Hi, Ben Skeggs latest changes in Mesa cause a build failure (libdrm is latest git ...). Thanks. Johannes gmake[3]: Entering directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers' gmake[4]: Entering directory `/usr/src/packages/BUILD/Mesa/src/mesa/drivers/dri' sed -e 's, at INSTALL_DIR@,/usr,' -e 's, at INSTALL_LIB_DIR@,/usr/lib,' -e 's, at

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

On Sat, Dec 19, 2015 at 1:53 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > These are supported on GK20A and GM107. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > > Was a bit torn on where to place the enums... we're about to gut all > the xml definitions so this seemed appropriate for now. > > Tested on GK20A only. > >

These are supported on GK20A and GM107. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Was a bit torn on where to place the enums... we're about to gut all the xml definitions so this seemed appropriate for now. Tested on GK20A only. src/gallium/drivers/nouveau/nv50/nv50_formats.c | 64 +++++++++++++++++++++++++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 10 ++++

Dear All, We aim to remove the spatial structure of our data using Moran Eigen Vectors and spdep package . Our data has 3694 samples and 13 variables. The computer stop working after almost 4 days of processing (we found it emitting a sharp sound and with all colors on the screen. No wories, it was restared without problem!). And we are left with nothing: no result file was produced since the

On some systems, putting vertex and index buffers in VRAM instead of GART memory eliminates massive graphics corruption which is otherwise present, due to unclear causes. This patch adds an environment variable that does that, along with helpful messages, prompting the user the report his configuration if we got the default setting wrong. It turns it on by default on NV49, as it is what I am

- This avoids problematic "reloc'ed while mapped" messages and some associated corruption as well. - Also add one nouveau_bo_unmap() in the vbo code that wasn't present. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_screen.c | 21 +++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 3 +++

- This avoids some problematic "reloc'ed while mapped" messages and some associated corruption as well. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- src/gallium/drivers/nouveau/nouveau_screen.c | 21 +++++++++++++++++++++ src/gallium/drivers/nouveau/nouveau_screen.h | 3 +++ src/gallium/drivers/nouveau/nouveau_stateobj.h | 20 +++++++++++++++++++-

https://bugs.freedesktop.org/show_bug.cgi?id=97900 Bug ID: 97900 Summary: [regression] nouveau_screen.c:230:2: error: implicit declaration of function ‘nouveau_drm_del’ Product: Mesa Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority:

From: Ben Skeggs <bskeggs at redhat.com> The winsys layer would attempt to cleanup the nouveau_device if screen init failed, however, in most paths the pipe driver would have already destroyed it, resulting in accesses to freed memory etc. This commit fixes the problem by allowing the winsys to detect whether the pipe driver's destroy function needs to be called or not. Signed-off-by:

On 12/07/2015 01:40 PM, Ilia Mirkin wrote: > This all seems very roundabout... Can't we do this in a somewhat > consistent way with the device being cleaned up in one place or > another but not both? That would be lovely, but not possible. It has to be cleaned up by the pipe screen destroy() function, as that's the normal exit path. If the pipe driver creation path fails before

On Sun, Dec 6, 2015 at 10:48 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 12/07/2015 01:40 PM, Ilia Mirkin wrote: >> This all seems very roundabout... Can't we do this in a somewhat >> consistent way with the device being cleaned up in one place or >> another but not both? > That would be lovely, but not possible. It has to be cleaned up by the > pipe

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:

This all seems very roundabout... Can't we do this in a somewhat consistent way with the device being cleaned up in one place or another but not both? On Thu, Nov 26, 2015 at 8:04 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > From: Ben Skeggs <bskeggs at redhat.com> > > The winsys layer would attempt to cleanup the nouveau_device if screen > init failed, however, in

Overall idea: Detect lockups by watching for timeouts (vm flush / fence), return -EIOs, handle them at ioctl level, reset the GPU and repeat last ioctl. GPU reset is done by doing suspend / resume cycle with few tweaks: - CPU-only bo eviction - ignoring vm flush / fence timeouts - shortening waits Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- Tested only on nv92. ---

Apparently some players are ill-prepared for us claiming that a decoder exists only to have creating it fail, and express this poor preparation with crashes (e.g. flash). Check that firmware is there to increase the chances of there being a high correlation between reported capabilities and ability to create a decoder. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: 10.0 10.1