similar to: [Bug 43428] New: Segmentation Fault in nv50_screen_fence_update

Displaying 13 results from an estimated 13 matches similar to: "[Bug 43428] New: Segmentation Fault in nv50_screen_fence_update"

2015 Jan 02
0
[PATCH] nv50: enable texture compression
As I mentioned on IRC, I think that some color formats are compressible. Would be nice to figure out which... e.g. trace the blob, or just try stuff. On Thu, Jan 1, 2015 at 9:56 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > We enable compression only for some supported formats > > Suggested-by: Ilia Mirkin <imirkin at alum.mit.edu> >
2015 Jan 02
2
[PATCH] nv50: enable texture compression
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
2006 Jul 27
7
suspicious memory usages
Following is the output of top command at my server and i find the high usage very much alarming. We are basically a team of three developers working on same machine(remotely), so we run mongrel_rails servers from out ~/public/app directories. We also run a cluster of mongrel servers using apache2.2. Is this much memory use normal? PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
2012 Dec 09
3
[LLVMdev] pb05 benchmarks for llvm/dragonegg 3.2
Duncan, With the commit from http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121203/158488.html, the Polyhedron 2005 benchmarks complete again on x86_64-apple-darwin12. The result are similar to what were seen with FSF gcc 4.6.2svn and llvm/dragonegg 3.0 (which was the last release that passed pb05) http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044091.html. Jack
2014 Jun 16
2
[PATCH 1/2] gallium/nouveau: decouple nouveau_fence implementation from screen
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4
2012 Dec 10
0
[LLVMdev] pb05 benchmarks for llvm/dragonegg 3.2
Hi Jack, thanks for these numbers. > With the commit from http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121203/158488.html, > the Polyhedron 2005 benchmarks complete again on x86_64-apple-darwin12. The result are similar to what > were seen with FSF gcc 4.6.2svn and llvm/dragonegg 3.0 (which was the last release that passed pb05) >
2009 Dec 31
1
[PATCH] Autogenerate uureg opcode macros
Also some missing _src()s and cosmetic changes. --- src/gallium/programs/galliumut/Makefile | 5 + .../programs/galliumut/gen_uureg_opcodes.sh | 29 +++ src/gallium/programs/galliumut/uureg.h | 196 ++++---------------- 3 files changed, 71 insertions(+), 159 deletions(-) create mode 100644 src/gallium/programs/galliumut/gen_uureg_opcodes.sh diff --git
2012 Mar 14
13
[Bug 47306] New: segfault in nouveau_fence_update
https://bugs.freedesktop.org/show_bug.cgi?id=47306 Bug #: 47306 Summary: segfault in nouveau_fence_update Classification: Unclassified Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Driver/nouveau
2006 Aug 05
0
Memory Usage after upgrading to pre-release and removing sendfile
After the upgrade my memory usage is shown like this: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4592 flipl 16 0 197m 150m 2360 S 0.0 14.9 6:17.28 mongrel_rails 4585 mongrel 16 0 190m 140m 1756 S 0.0 13.9 0:52.86 mongrel_rails 4579 mongrel 16 0 200m 157m 1752 S 0.0 15.5 0:56.31 mongrel_rails 4582 mongrel 16 0 189m 139m 1752 S 0.0 13.8
2014 Jun 17
2
[PATCH try 2 1/2] gallium/nouveau: decouple nouveau_fence implementation from screen
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4 +-
2014 Jun 17
0
[PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the entire notifier, and use a offset in nv30_context_kick_notify. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 14 +- src/gallium/drivers/nouveau/nouveau_context.h | 5 +
2014 Jun 21
3
[Mesa-dev] [PATCH try 2 2/2] gallium/nouveau: move pushbuf and fences to context
On Tue, Jun 17, 2014 at 2:34 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the > entire notifier, and use a offset in nv30_context_kick_notify. It would be great if you could detail the list of transformations that were done in the commit description, as well as what the
2006 Jan 27
2
php-ldap can't log on with browser
It has been some posting about this issue, but I cant find a solution I can't log on to my ldap server port 389 with my browser. service seems to be running. I am not running selinux, port 389 are open on both client and server. Message from browser: Access to this port is disabled for security reasons. Added command (hint from earlier posting) and got this list # netstat -aptn | grep