glxinfo weird error, please help

Please Help, thank you very much!! Code: $ export LIBGL_DEBUG=verbose $ glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 5.2.0 radeon (screen 0) libGL: OpenDriver: trying /usr/lib/dri/tls/radeon_dri.so libGL: OpenDriver: trying /usr/lib/dri/radeon_dri.so libGL: XF86DRIGetClientDr

Re: glxinfo weird error, please help

Alec Liu wrote: > Please Help, thank you very much!! > Code: > > $ export LIBGL_DEBUG=verbose > > $ glxinfo > name of display: :0.0 > libGL: XF86DRIGetClientDriverName: 5.2.0 radeon (screen 0) > libGL: OpenDriver: trying /usr/lib/dri/tls/radeon_dri.so > libGL: OpenDriver: trying /usr/lib/dri/rad

Re: Initial 915 superioctl patch.

On Sunday, October 7, 2007 4:26 pm Dave Airlie wrote: > > At a high level, I'm wondering if something like this could be made > > more generic... It seems like other GPUs will need similar > > relocation processing so maybe the DRM should grow some generic > > reloc processing code? Much of this

Re: DRM_READ/WRITE* vs. byte swapping (Re: drm: Branch 'master')

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michel Dänzer wrote: > On Wed, 2007-10-03 at 14:08 -0700, Ian Romanick wrote: >> diff --git a/linux-core/xgi_cmdlist.c b/linux-core/xgi_cmdlist.c >> index 261f4e1..35f7e1b 100644 >> --- a/linux-core/xgi_cmdlist.c >> +++ b/linux-core/xgi_cmdlist.c >> @@

[Bug 6689] libGL warning: 3D driver claims to not support visual 0x51

http://bugs.freedesktop.org/show_bug.cgi?id=6689 [EMAIL PROTECTED] changed: What|Removed |Added Summary|libGL warning: 3D driver|libGL warning: 3D driver

Re: Initial 915 superioctl patch.

Neither 42 nor 256 are very good - the number needs to be dynamic. Think about situations where an app has eg. one glyph per texture and is doing font rendering... Or any reasonably complex game might use >256 textures in a frame. Sorry for topposting -- webmail. Keith - Original Messa

Re: glxinfo weird error, please help

Alec Liu wrote: > i am using the gentoo > i did compile everything > > please help me to local the badly compiled library > thank you ! > > On 10/9/07, Jerome Glisse <[EMAIL PROTECTED]> wrote: > >> Alec Liu wrote: >> >>> Please Help, thank you very much!! >>> Code: >>> >>> $ export LIBG

Re: Initial 915 superioctl patch.

On Monday, October 8, 2007 10:13 am Keith Whitwell wrote: > Neither 42 nor 256 are very good - the number needs to be dynamic. > Think about situations where an app has eg. one glyph per texture and > is doing font rendering... Or any reasonably complex game might use > >256 textures in a frame.

Re: glxinfo weird error, please help

Alec Liu wrote: > btw: should i send the mail to the dri-devel@lists.sourceforge.net > or just click the reply. > this is my fist time using the mail list, and you are the first reply > i got. thank you again!! > > On 10/9/07, Jerome Glisse <[EMAIL PROTECTED]> wrote: > >> Alec Liu wrote: >>

Re: fix "undefined symbol: ALIGN" on /usr/lib/dri/i915_dri.so

On Mon, 2007-10-08 at 01:16 +0100, Sergio Monteiro Basto wrote: > Hi, > this patch fix my problem , > > --- a/src/mesa/drivers/dri/intel/intel_tex_layout.c > +++ b/src/mesa/drivers/dri/intel/intel_tex_layout.c > @@ -33,6 +33,7 @@ > #include "intel_mipmap_tree.h" > #include "intel_tex_layout.h"

[Bug 12731] dri is disabled with i915 driver

http://bugs.freedesktop.org/show_bug.cgi?id=12731 --- Comment #1 from [EMAIL PROTECTED] 2007-10-08 12:45 PST --- Already fix on git master : Commit: 4599683b480d295e407725e0fe99c357a0086092 i915: Fix undefined ALIGN symbol from 77e0523fb7769df4bf43747e136b1653b2421b97. you may clos

Re: i945GM / drm-modesetting-101 vs Xorg (Xorg : 1 / drm-modesetting-101 : 0, 5) :-)

Hi, I tried to check the timing stuff but (as I'm not a real developper) I don't know how to test my timings easily. Until now, I did several tries with no luck... In fact, for each try, I have to compile the module, load it, check what's going on and the reboot. I must reboot because the modeset

Re: Initial 915 superioctl patch.

> On Monday, October 8, 2007 10:13 am Keith Whitwell wrote: >> Neither 42 nor 256 are very good - the number needs to be dynamic. >> Think about situations where an app has eg. one glyph per texture and >> is doing font rendering... Or any reasonably complex game might use >>> 256 textures in a f

Re: Initial 915 superioctl patch.

On Monday, October 8, 2007 2:14 pm Dave Airlie wrote: > > On Monday, October 8, 2007 10:13 am Keith Whitwell wrote: > >> Neither 42 nor 256 are very good - the number needs to be dynamic. > >> Think about situations where an app has eg. one glyph per texture > >> and is doing font rendering... Or

Re: i945GM / drm-modesetting-101 vs Xorg (Xorg : 1 / drm-modesetting-101 : 0, 5) :-)

On Monday, October 8, 2007 2:00 pm Philippe Gaultier wrote: > Hi, > > I tried to check the timing stuff but (as I'm not a real developper) > I don't know how to test my timings easily. > Until now, I did several tries with no luck... > > In fact, for each try, I have to compile the module, load it,

Re: Initial 915 superioctl patch.

Dave Airlie wrote: > >> On Monday, October 8, 2007 10:13 am Keith Whitwell wrote: >>> Neither 42 nor 256 are very good - the number needs to be dynamic. >>> Think about situations where an app has eg. one glyph per texture and >>> is doing font rendering... Or any reasonably complex game might us

driver fence_type function

Hi Thomas (any anyone else :-) drm_buffer_object_validate gets passed new and old flags (using bo->mem.mask/bo->mem.flags) but when it calls the i915 fence_type function it only uses flags to check the fence type, now if this buffer is getting validated RW when it wasn't before, it will get t

[patch] post superioctl inteface removal.

Hi, Once the 915 super ioctl is merged, the patch attached removes the unused interfaces left behind... Are any of these worth saving? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG From 5bb96b72c503953a