OpenGL 2.0 specification available for download

Hi all! From the www.opengl.org: OpenGL 2.0 specification available for download http://www.opengl.org/documentation/opengl_current_version.html http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Any plans for 2.0 support in Mesa? I think the biggest todo is the sw-emulation of

[R200] Lockups after few time in America's Army

Hi all, I'm using a 3D prophet Radeon 8500LE and the lastest DRI drivers from CVS + S3TC patch . I've noticed that I can't play to ArmyOps , because after few time I've started the game the game image simply freeze . I can hear the sound of the game, but I can't do anything. CTRL + ALT +

Re: initmap code

On Iau, 2004-09-09 at 00:45, Ian Romanick wrote: So, what happens in x86-64 where sizeof(unsigned long) is 4 bytes for IA-32 apps and 8 bytes for x86-64 apps? I guess since it's a parameter to the ioctl (rather than embedded in a structure) it should be okay, but I just want to be sure...

Re: OpenGL 2.0 specification available for download

Pasi Kärkkäinen wrote: Hi all! From the www.opengl.org: OpenGL 2.0 specification available for download http://www.opengl.org/documentation/opengl_current_version.html http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Any plans for 2.0 support in Mesa? I think the biggest todo is

Re: initmap code

On 09.09.2004, at 15:02, Alan Cox wrote: So, what happens in x86-64 where sizeof(unsigned long) is 4 bytes for IA-32 apps and 8 bytes for x86-64 apps? I guess since it's a parameter to the ioctl (rather than embedded in a structure) it should be okay, but I just want to be sure... Be cautious

Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download

Brian Paul schrieb: Pasi Kärkkäinen wrote: Hi all! From the www.opengl.org: OpenGL 2.0 specification available for download http://www.opengl.org/documentation/opengl_current_version.html http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Any plans for 2.0 support in Mesa? I think

radeon-pre-2

Hey, as I'm slowly ploughing through the last changes to get BSD support working again... the radeon-pre-2 patch added linux-only code to radeon_cp.h, somehow to establish permanent mappings for framebuffer and mmio, as it seems. this is not good. is there an OS independent way to do this?

Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download

Philipp Klaus Krause wrote: Brian Paul schrieb: Pasi Kärkkäinen wrote: Hi all! From the www.opengl.org: OpenGL 2.0 specification available for download http://www.opengl.org/documentation/opengl_current_version.html http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Any plans for

Re: radeon-pre-2

This is what I'm talking about with hotplug support and BSD not supporting hotplug. On Linux there are rules for dealing with all of the resources so that you don't get conflicts with new devices when they are plugged in. It's the region code that is causing problems right? If so, register/release

Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download

On Thu, Sep 09, 2004 at 05:03:27PM +0200, Philipp Klaus Krause wrote: Brian Paul schrieb: Pasi Kärkkäinen wrote: Hi all! From the www.opengl.org: OpenGL 2.0 specification available for download http://www.opengl.org/documentation/opengl_current_version.html

Nightly doxygen documentation

Hi, Doxygen documentation of DRM and Mesa is generated every night from CVS into http://freedesktop.org/~dri/doxygen/ . Enjoy, José Fonseca --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an

Re: radeon-pre-2

On 09.09.2004, at 19:37, Jon Smirl wrote: This is what I'm talking about with hotplug support and BSD not supporting hotplug. On Linux there are rules for dealing with all of the resources so that you don't get conflicts with new devices when they are plugged in. It's the region code that is

Re: radeon-pre-2

I'm not sure why this stuff is directly called from radeon_cp.c (and only this driver) and not from within the common code path. Isn't this also done via becase the DRM is undergoing experimental surgery at the moment, and the radeon is the crash test dummy ... I think two drivers need to be

Re: radeon-pre-2

Neither of these have anything to do with the addmap/initmap change. request/release regions is what Linux drivers are supposed to do to mark that they have a resource in use. There's a pci_request_region() available that hides whether it is IO or memory so I should switch to that one. All

Re: Nightly doxygen documentation

José Fonseca wrote: Hi, Doxygen documentation of DRM and Mesa is generated every night from CVS into http://freedesktop.org/~dri/doxygen/ . Enjoy, Thanks, José. I added new sections for the glapi and shader modules and tweaked a few other things. Hopefully I didn't break anything. -Brian

Re: radeon-pre-2

request/release regions is what Linux drivers are supposed to do to mark that they have a resource in use. There's a pci_request_region() available that hides whether it is IO or memory so I should switch to that one. All drivers should implement these functions. You can't do this as part of

Re: radeon-pre-2

This should fix it in general for all cards and make it into Linux specific code. I gave it a minimal test and it works for me. If it's working right cat /proc/iomem /proc/ioports will show the driver as owning the resources. pci_request_regions() will fail if called in stealth mode so it needs

drm_bufs.h: order as an OS specific way of computation?

What would be the method for submiting a patch to to move this into non-OS_specific code? Here is the current diff from Linux to BSD... -/** - * Compute size order. Returns the exponent of the smaller power of two which - * is greater or equal to given number. - * - * \param size size. - *