Re: [Mesa3d-dev] Please HELP!!! accumulation buffers support FC9
On Wed, 2008-08-06 at 18:12 -0600, Brian Paul wrote: Svilen wrote: 3 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x52 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 16 GLXFBConfigs: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x53 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x54 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x55 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x56 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x57 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x58 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x59 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x5a 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x5b 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x5c 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x5d 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x5e 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x5f 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x60 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x61 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x62 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow First, maybe another R300 user can say what 'glxinfo' says on their system. I get the same. Off hand I'd expect more GLX visuals and fewer FBConfigs. It's due to Kristian Høgsberg's GLX visual reworks. I think the idea is to only have GLX visuals for the common use cases by default and to stick to FBConfigs otherwise. There's a xorg.conf Option GlxVisuals to change this though which is documented in the xorg.conf manpage. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17023] New: [i965] glean/api2 triggers assertion failure
http://bugs.freedesktop.org/show_bug.cgi?id=17023 Summary: [i965] glean/api2 triggers assertion failure Product: Mesa Version: 7.1 Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i965 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: dri-devel@lists.sourceforge.net System Environment: -- --Platform: Q965 --2D driver: commit f91134795b545c8baebf218975b261c76a0e5873 --3D driver: commit c20a1736566d301f38cc1271284b1fde9adb2741 --Xserver: commit 26d31ad1c7f4c550d73419ecf76912d844186b30 --Drm commit 4585787bd1a1d782b9e7c06095f98d09165b8c23 --Kernel: 2.6.25 Bug detailed description: - glean case api2 failed with assertion failure, bisect shows following commit brings in this issue: ffbc66bf614c5a2b9bc3a68a6fa7d027405a55b9 is first bad commit commit ffbc66bf614c5a2b9bc3a68a6fa7d027405a55b9 Author: Brian Paul [EMAIL PROTECTED] Date: Mon Jul 21 13:58:50 2008 -0600 mesa: assorted glsl uniform/attribute fixes Fix incorrect uniform/attribute size query results. Add missing error checking for glUniform, glUniformMatrix params Fix an array size/allocation error. assertion failure with this commit is: glean: shader/shader_api.c:541: _mesa_bind_attrib_location: Assertion `0'failed assertion failure with git tip is: glean: brw_vs_emit.c:613: get_reg: Assertion `c-regs[file][index].nr != 0\' failed backtrace: (gdb) bt #0 0xe424 in __kernel_vsyscall () #1 0x00bfd690 in raise () from /lib/libc.so.6 #2 0x00bfef91 in abort () from /lib/libc.so.6 #3 0x00bf693e in __assert_fail () from /lib/libc.so.6 #4 0xb7b67501 in _mesa_bind_attrib_location (ctx=0x810c568, program=9, index=6, name=0x80b87af generic) at shader/shader_api.c:541 #5 0xb7be9d9c in _mesa_BindAttribLocationARB (program=9, index=6, name=0x80b87af generic) at main/shaders.c:66 #6 0x08058cb5 in GLEAN::API2Test::testShaderAttribs (this=0x80ef460) at tapi2.cpp:758 #7 0x08057fd1 in GLEAN::API2Test::runSubTests (this=0x80ef460, [EMAIL PROTECTED]) at tapi2.cpp:990 #8 0x0805a39a in GLEAN::API2Test::runOne (this=0x80ef460, [EMAIL PROTECTED], [EMAIL PROTECTED]) at tapi2.cpp:1007 #9 0x0805ad85 in GLEAN::BaseTestGLEAN::MultiTestResult::run ( this=0x80ef460, [EMAIL PROTECTED]) at tbase.h:290 #10 0x080547eb in main (argc=6, argv=0xbfd1d4e4) at main.cpp:128 Current result: glean case api2 run abort Expected result: glean case api2 should pass -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17023] [i965] glean/api2 triggers assertion failure
http://bugs.freedesktop.org/show_bug.cgi?id=17023 --- Comment #1 from Shuang He [EMAIL PROTECTED] 2008-08-07 00:26:38 PST --- Created an attachment (id=18169) -- (http://bugs.freedesktop.org/attachment.cgi?id=18169) xorg log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17023] [i965] glean/api2 triggers assertion failure
http://bugs.freedesktop.org/show_bug.cgi?id=17023 --- Comment #2 from Shuang He [EMAIL PROTECTED] 2008-08-07 00:27:42 PST --- Created an attachment (id=18170) -- (http://bugs.freedesktop.org/attachment.cgi?id=18170) xorg conf -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Please HELP!!! accumulation buffers support FC9
Am Donnerstag 07 August 2008 01:48:07 schrieb Svilen: I'm having troubles obtaining GLX visual with accumulation buffers. It happens only on Fedora 9. Attached is glxinfo log. Problem never appears with fglrx drivers, but as you know it's not available for FC9. I'm really looking forward for your comments. Here is my platform: X1600 Mobility Radeon Linux, Fedora 9 Xorg 7.4 (unofficial) Mesa 7.1 (unofficial) xorg.conf ... Section Device Identifier Videocard0 Driver radeon EndSection ... Regards I don't think we have acceleration for accumulation buffers. You may still be able to obtain a GLX visual with accum buffers by what Michel said, but don't expect too great results. To be honest, you're the first person I've ever seen complaining about missing accumulation buffers, so I have no idea whether that will change any time soon. cu, Nicolai - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: OpenGL 3.0 release at siggraph
On Wed, Aug 06, 2008 at 11:55:29AM -0700, Ian Romanick wrote: Pasi Kärkkäinen wrote: | It seems OpenGL 3.0 will be (finally) released at Siggraph! Yes, finally. :) | http://www.khronos.org/news/events/detail/siggraph_2008_los_angeles_california// | | OpenGL BOF | | SIGGRAPH 2008 | Wednesday, 13 August | 6:00 pm - 8:00 pm | Wilshire Grand Hotel - Wilshire Room I will be at SIGGRAPH and at the BoF this year...in case anyone wants to meet up and hang out or something. Nice. Too bad I can't be there. Would be nice to see Siggraph once.. Maybe you can post here and let us know what happened and how it was :) -- Pasi - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] radeon_cp: use request_firmware
On Thursday 07 August 2008, Jaswinder Singh wrote: Moved datah before datal because datah is required before datal. Firmware blob looks like this... __be32 datah __be32 datal Signed-off-by: Jaswinder Singh [EMAIL PROTECTED] When applied to 2.6.27-rc2, firmware/Makefile was rejected, so I manually added the blob list to that Makefile in what looked to be the correct place. And added a make firmware_install to my kernel builder script. Unforch: MK_FW firmware/R100_cp.bin.ihex.gen.S make[1]: *** No rule to make target `firmware/R100_cp.bin.ihex', needed by `firmware/R100_cp.bin.ihex.gen.o'. Stop. make[1]: *** Waiting for unfinished jobs make: *** [firmware] Error 2 I suspect I need to go back and hand edit the .config to add the radeon/ in front of each of those, so its looking for firmware/radeon/R100_cp.bin.ihex in each of those cases. Correct? Or can I use radeon/* ? [...] -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Fiber optics caused gas main leak - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Please HELP!!! accumulation buffers support FC9
On 07.08.2008 09:08, Michel Dänzer wrote: On Wed, 2008-08-06 at 18:12 -0600, Brian Paul wrote: Svilen wrote: 3 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x52 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 16 GLXFBConfigs: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x53 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x54 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x55 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x56 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x57 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x58 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x59 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x5a 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x5b 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x5c 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x5d 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x5e 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x5f 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x60 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x61 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x62 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow First, maybe another R300 user can say what 'glxinfo' says on their system. I get the same. Off hand I'd expect more GLX visuals and fewer FBConfigs. It's due to Kristian Høgsberg's GLX visual reworks. I think the idea is to only have GLX visuals for the common use cases by default and to stick to FBConfigs otherwise. There's a xorg.conf Option GlxVisuals to change this though which is documented in the xorg.conf manpage. Hmm, typical and minimal seem to do the same thing. I'm not sure though I understand the rationale behind not exporting the full set, just because fb configs exists old apps are not magically going to use them. Also, glx (1.2, 1.3 does mention this only for fb configs but I'm sure it would apply there just as well due to backward compatibility) requires that a visual with a accumulation buffer be exported. Therefore, the minimal (and typical) set are not enough to satisfy glx requirements as they do not include any visual with an accumulation buffer. Roland - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Please HELP!!! accumulation buffers support FC9
Nicolai Hähnle wrote: Am Donnerstag 07 August 2008 01:48:07 schrieb Svilen: I'm having troubles obtaining GLX visual with accumulation buffers. It happens only on Fedora 9. Attached is glxinfo log. Problem never appears with fglrx drivers, but as you know it's not available for FC9. I'm really looking forward for your comments. Here is my platform: X1600 Mobility Radeon Linux, Fedora 9 Xorg 7.4 (unofficial) Mesa 7.1 (unofficial) xorg.conf ... Section Device Identifier Videocard0 Driver radeon EndSection ... Regards I don't think we have acceleration for accumulation buffers. You may still be able to obtain a GLX visual with accum buffers by what Michel said, but don't expect too great results. To be honest, you're the first person I've ever seen complaining about missing accumulation buffers, so I have no idea whether that will change any time soon. I'm certainly not a great expert in OpenGL, but accumulation buffers can be quite handy. It seems highly unlikely that I'm the only one using them. Besides you can find a simple tricks with the accumulation buffers in every openGL book. It is certainly a surprise that I'm the first complaining about it. It certainly took me some time until I found the right place to ask the question. Maybe this is one of the reasons? Svilen - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Please HELP!!! accumulation buffers support FC9
Michel Dänzer wrote: On Wed, 2008-08-06 at 18:12 -0600, Brian Paul wrote: Svilen wrote: 3 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x52 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 16 GLXFBConfigs: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x53 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x54 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x55 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x56 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x57 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x58 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x59 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x5a 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x5b 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x5c 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x5d 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x5e 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x5f 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x60 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x61 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x62 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow First, maybe another R300 user can say what 'glxinfo' says on their system. I get the same. Off hand I'd expect more GLX visuals and fewer FBConfigs. It's due to Kristian Høgsberg's GLX visual reworks. I think the idea is to only have GLX visuals for the common use cases by default and to stick to FBConfigs otherwise. There's a xorg.conf Option GlxVisuals to change this though which is documented in the xorg.conf manpage. Phew! That was easy! Section ServerLayout ... Option GlxVisuals all EndSection ... and job done! Well, maybe it's too early to jump ?! Thanks Michel! A couple of questions. - Does anybody knows whether this is a problem with nVidia cards as well ? - What is the rationale behind hiding GLX visuals by default? Memory? Speed? - What was the version that introduced this change? - Maybe I need to read first about FBconfigs. Any links? Sorry about asking more questions, but I believe the answers will be helpful not only to me Regards Svilen - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Please HELP!!! accumulation buffers support FC9
Svilen wrote: Nicolai Hähnle wrote: Am Donnerstag 07 August 2008 01:48:07 schrieb Svilen: I'm having troubles obtaining GLX visual with accumulation buffers. It happens only on Fedora 9. Attached is glxinfo log. Problem never appears with fglrx drivers, but as you know it's not available for FC9. I'm really looking forward for your comments. Here is my platform: X1600 Mobility Radeon Linux, Fedora 9 Xorg 7.4 (unofficial) Mesa 7.1 (unofficial) xorg.conf ... Section Device Identifier Videocard0 Driver radeon EndSection ... Regards I don't think we have acceleration for accumulation buffers. You may still be able to obtain a GLX visual with accum buffers by what Michel said, but don't expect too great results. To be honest, you're the first person I've ever seen complaining about missing accumulation buffers, so I have no idea whether that will change any time soon. I'm certainly not a great expert in OpenGL, but accumulation buffers can be quite handy. It seems highly unlikely that I'm the only one using them. Besides you can find a simple tricks with the accumulation buffers in every openGL book. It is certainly a surprise that I'm the first complaining about it. It certainly took me some time until I found the right place to ask the question. Maybe this is one of the reasons? I agree that a GLX visual with an accum buffer should be present. Accum is always implemented in software with Mesa, but it's trivial to support. -Brian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] radeon_cp: use request_firmware
Hello Gene, On Thu, 2008-08-07 at 06:24 -0400, Gene Heskett wrote: When applied to 2.6.27-rc2, firmware/Makefile was rejected, so I manually added the blob list to that Makefile in what looked to be the correct place. And added a make firmware_install to my kernel builder script. Unforch: MK_FW firmware/R100_cp.bin.ihex.gen.S make[1]: *** No rule to make target `firmware/R100_cp.bin.ihex', needed by `firmware/R100_cp.bin.ihex.gen.o'. Stop. make[1]: *** Waiting for unfinished jobs make: *** [firmware] Error 2 It seems your firmware/Makefile is not good. it should look like this :- fw-shipped-$(CONFIG_DRM_RADEON) += radeon/R100_cp.bin radeon/R200_cp.bin \ radeon/R300_cp.bin radeon/R420_cp.bin \ radeon/RS600_cp.bin radeon/RS690_cp.bin \ radeon/R520_cp.bin I think you forget to write radeon before R100_cp.bin And you can collect my updated patch from : http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git Thank you, Jaswinder Singh. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/1] Adapt on_each_cpu
On Thu, 2008-07-31 at 19:53 -0700, Jesse Barnes wrote: On Thursday, July 31, 2008 6:40 pm Dave Airlie wrote: Well, if the overhead of merging upstream is a concern, then how about not worrying about bc at all and let people who want to back port deal with it? Oh, and what about just keeping the drm drivers in a linux kernel tree? That'll make upstream merging even easier yet... The less crap I have to remove from the diffs the better, I have a script and it removes stuff mostly fine, maybe someone should actually bring this idea up on the list with a proper plan for how to deal with a) BSD I'd like to hear Robert's concerns here, but I've been working with some of the BSD folks lately, and it seems like the main concerns are: 1) making it easy for contributors to identify which portions of code are shared 2) licensing Since both the BSDs and Linux effectively copy code out of the DRM repo and into their respective kernel trees at this point, having the actual repo based on one of them shouldn't be an issue as long as both 1 and 2 are handled. The remaining compat macros could probably just be wrapped in some sort of Linux equivalent (DRM_SPINUNLOCK-spin_unlock, what's the difference?), or we could annotate things for the BSD guys to run scripts over. As it stands, they still have to go over things by hand anyway... As an ex-BSD kernel maintainer, I stood against moving to a linux kernel-based tree for a long time. For a long time I felt like I was the only guy holding back the move. I couldn't get NetBSD to work in the upstream tree, and it sounds like OpenBSD's following the same route, so maybe I was doing it wrong all along in trying to have one tree for all OSes to share. Entries 1 and 2 in the list were of concern to me for quite some time, as those championing the move to a linux tree were doing it primarily for GPL and style motivations (at least vocally). I didn't like the GPL motivation, and felt like we had other avenues to fix the style motivation (which I eventually worked on, and was about half done with I think). The other problem as a BSD maintainer was how to merge code. Originally all I had available was CVS and cp, so the shared-code system we had was useful -- I just worked in the DRM tree and periodically copied changes over and cvs committed. Eventually I got perforce access, and was trying to use that to manage merges, but CVS IDs and perforce diff formatting and performance issues made it more work than copying diffs by hand. I settled on a series of seds on the DRM tree and cping it to the BSD tree, which worked reasonably well. Luckily, those times are past. We've got git now. If I was doing BSD at this point, I would probably rather set it up as a branch of a linux-2.6 kernel tree that I merged from: Initial setup today: cd linux-2.6 git-checkout -b freebsd-drm cd drivers/gpu/drm cp ~/src/drm/bsd-core/drm*.[ch] . cp ~/src/drm/bsd-core/i915/Makefile i915/ cp ~/src/drm/bsd-core/i915*.[ch] i915/ (etc) git-add . git-commit -a -v Next merges: git-merge origin/master (resolve conflicts and make it compile again as linux-specific bits trickle in) git commit -a Then I could use my old script for copying an external tree into the FreeBSD repo and continue doing mega-commits as before. The advantage here is that since I'm merging the linux-specific OS side, I don't have to go and read the two side-by-side all the time to make sure they haven't drifted too far apart, which was almost all of the time I spent working on the BSD code. This is assuming that the two codebases stay close enough together for the merger to do something sane, but I think that would be the case for the most part. To improve that, I'd add more compat macros to leave the FreeBSD side more linux-looking. FreeBSD's grown a layer for taking osol code mostly as-is for the ZFS and dtrace ports, and I think growing some compatibility for taking mostly linux-looking code would probably be a sensible plan for maintaining this codebase, and would probably help various other potential FreeBSD projects as well. I don't think anyone is proposing changing the licensing of DRM code this time around, so with this plan as a BSD guy I wouldn't even care which parts of the code were shared versus os-specific. b) backwards compat for using updated DRM drivers on older kernels. Since I'm now maintaining a linux-2.6 tree for getting my GEM work merged, I'm having to deal with backporting concerns already. The plan I'm proposing for our project is for us to do topic branches like other linux kernel developers, propose them for merge either through you or directly, and maintain one branch for all the things I want on top of current linux kernel to get what we need. As we head towards our quarterly release, I'll prepare a branch against the latest released kernel of everything we need for the quarterly release, which is then the stuff that backporters would
