[Bug 21056] PowerBook G4, PowerMac G5, ATI HW Rendering Fails

2009-04-05 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=21056 --- Comment #1 from Jeremy Huddleston jerem...@freedesktop.org 2009-04-04 23:00:28 PST --- This bug doesn't exist using trunk, so it seems to have been eliminated somewhere along the line. It would be nice if it could find its way into the

[Bug 12836] 2.6.29-rc breaks STD using Intel 945

2009-04-05 Thread bugzilla-daemon
http://bugzilla.kernel.org/show_bug.cgi?id=12836 --- Comment #1 from Rafael J. Wysocki r...@sisk.pl 2009-04-05 10:54:22 --- On Monday 16 March 2009, Frank Seidel wrote: Sitsofe Wheeler wrote: Hmm. Does switching to and then back from a virtual terminal also break? I think i have the

[PATCH] radeon: Don't print results of microcode writeback if disabled

2009-04-05 Thread Matt Turner
Hi, The attached patch removes the case where something silly like the following could be printed to dmesg. [drm] writeback test failed [drm] writeback forced off Please commit (I don't have commit access). Thanks, Matt Turner 0001-radeon-Don-t-print-results-of-microcode-writeback-i.patch

[Bug 21065] New: Dungeon Siege Textures done work ( through Wine - Compiz disabled)

2009-04-05 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=21065 Summary: Dungeon Siege Textures done work (through Wine - Compiz disabled) Product: Mesa Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status:

Gallium HW Drivers DRI/DRM

2009-04-05 Thread demetrioussharpe
I'm not sure which list is the correct one to post these questions, so I'm posting to both.? All diagrams of the Gallium architecture show the ability of using Gallium in various OS's that are completely different with each other.? However, each diagram that has a specific graphics chipset

Re: [PATCH] radeon: Don't print results of microcode writeback if disabled

2009-04-05 Thread Matt Turner
One small change: if writeback test is disabled say 'writeback test disabled' instead of 'writeback disabled'. Matt On Sun, Apr 5, 2009 at 4:15 PM, Matt Turner matts...@gmail.com wrote: Hi, The attached patch removes the case where something silly like the following could be printed to

[Bug 21065] Dungeon Siege Textures done work ( through Wine - Compiz disabled)

2009-04-05 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=21065 --- Comment #1 from Reenen rlau...@gmail.com 2009-04-05 14:00:51 PST --- As soon as the textures bugs, I get this message in the console: fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface

Re: [Mesa3d-dev] Gallium HW Drivers DRI/DRM

2009-04-05 Thread Corbin Simpson
Right now, in order to create a driver, you need to combine three pieces. The pipe is the core of acceleration for a given chipset. It contains all of the code necessary to accelerate things, and exposes two generic structs in the Gallium API: pipe_screen, which is information about the current

Re: [Mesa3d-dev] Gallium HW Drivers DRI/DRM

2009-04-05 Thread Corbin Simpson
demetrioussha...@netscape.net wrote: So that means that I can get hardware acceleration by writing the winsys for Syllable, regardless of the fact that we don't use DRI/DRM?? I guess the main question is, Do I have to use the DRI/DRM drivers in order to use the current hardware pipes? And

Re: [Mesa3d-dev] Gallium HW Drivers DRI/DRM

2009-04-05 Thread demetrioussharpe
So that means that I can get hardware acceleration by writing the winsys for Syllable, regardless of the fact that we don't use DRI/DRM?? I guess the main question is, Do I have to use the DRI/DRM drivers in order to use the current hardware pipes? Dee -Original Message-

Re: [Mesa3d-dev] Gallium HW Drivers DRI/DRM

2009-04-05 Thread demetrioussharpe
Sounds good, but here's the catch, I would like to use Gallium to accelerate the whole windowing system.? I want our windowing system to use libGL for all rendering, so Gallium would basically be running on the video card with no windowing system standing in the way. Dee

Re: [Mesa3d-dev] Gallium HW Drivers DRI/DRM

2009-04-05 Thread Corbin Simpson
demetrioussha...@netscape.net wrote: Sounds good, but here's the catch, I would like to use Gallium to accelerate the whole windowing system.? I want our windowing system to use libGL for all rendering, so Gallium would basically be running on the video card with no windowing system

Re: [Mesa3d-dev] Gallium HW Drivers DRI/DRM

2009-04-05 Thread demetrioussharpe
Ok, that sounds good.? What we have right now is a very simple 2d driver API that basically blits bitmaps from userspace to the screen.? Our drivers have a duality system.? They use a kernel driver for basic access to the card, but for many drivers, almost everything is MMIO, so the kernel

[Bug 20869] alienarena causing error: i915_program_error: Exceeded max nr indirect texture lookups

2009-04-05 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=20869 --- Comment #1 from Eric Anholt e...@anholt.net 2009-04-05 19:31:05 PST --- Works fine for me as far as I can tell with Mesa master. Please provide the information requested in http://intellinuxgraphics.org/how_to_report_bug.html to see if

[Bug 20869] alienarena causing error: i915_program_error: Exceeded max nr indirect texture lookups

2009-04-05 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=20869 Eric Anholt e...@anholt.net changed: What|Removed |Added Keywords||NEEDINFO -- Configure

Re: Gallium HW Drivers DRI/DRM

2009-04-05 Thread Michel Dänzer
[ mesa3d-dev is more appropriate I think ] On Sun, 2009-04-05 at 16:38 -0700, Corbin Simpson wrote: demetrioussha...@netscape.net wrote: So that means that I can get hardware acceleration by writing the winsys for Syllable, regardless of the fact that we don't use DRI/DRM?? I guess the

Re: [PATCH] radeon: Don't print results of microcode writeback if disabled

2009-04-05 Thread Michel Dänzer
On Sun, 2009-04-05 at 16:56 -0400, Matt Turner wrote: One small change: if writeback test is disabled say 'writeback test disabled' instead of 'writeback disabled'. No, it's really about disabling the writeback of the ring head pointer and scratch register contents (not 'microcode writeback'),