Re: [r300] fragment.position patch (RFC)
On 11/16/06, Rune Petersen [EMAIL PROTECTED] wrote: Hi, I finally managed to iron out the last issue with getting a fully working fragment.position for the r300 driver. This should really require the big discussion if it wasn't for the fact that it depends on functional changes in r300_vertexprog.c (r300_select_vertex_shader4). The patches: r300_select_vertex_shader4: The patch makes the vertex program output from the fragment input. It makes the driver capable of catching output-input mismatches. primarily based on some of Aapo Tahkola's code. mesa-support_internal_driver_state_vars: Makes it possible for driver to define its own internal state parameters. r300_fragment_wpos5: Adds fragment.position support, depends on the above patches. Any questions/ideas/comments/??, I am all ears. Rune Petersen P.S. Brian, Roland, Keith, thank you for your patient replies. I can't comment on the mesa part (not familiar enought with that) otherwise i think your patch is good. Neverless i got the feeling that this vertex/fragprog input/output match maybe usefull to other driver in the future, maybe it would have been better to push that into mesa. One more things iirc Keith did somethings in mesa about position invariant and vertex program, can't remember exactly as i wasn't much looking in vertex shader at that time :) Anyway good job Rune :) best, Jerome Glisse - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8250] Warcraft player avatars not rendered correctly when GL_ARB_vertex_program enabled.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8250 --- Additional Comments From [EMAIL PROTECTED] 2006-11-17 04:20 --- (In reply to comment #28) (In reply to comment #27) Are you sure direct rendering worked for xscreensaver? I get exactly the same problem, but only with indirect rendering. In any case, I doubt it's related. Well, I can't think why xscreensaver wouldn't be using direct rendering. But if you think it's a separate issue then fair enough. Well, I've got some trouble sometimes with xscreensaver not getting direct rendering (where all other apps work). However, I can reproduce it with direct rendering, if I set tcl_mode to 0 or 1. So there definitely is a problem here, it certainly should look the same regardless of tcl mode. It could be related to warcraft problems, though that's difficult to say. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8874] xorg crashes when switching virtual console with mga g550
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8874 --- Additional Comments From [EMAIL PROTECTED] 2006-11-17 05:52 --- Edit comment #3: My card is a G200 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] fragment.position patch (RFC)
Rune Petersen wrote: Hi, I finally managed to iron out the last issue with getting a fully working fragment.position for the r300 driver. This should really require the big discussion if it wasn't for the fact that it depends on functional changes in r300_vertexprog.c (r300_select_vertex_shader4). The patches: r300_select_vertex_shader4: The patch makes the vertex program output from the fragment input. It makes the driver capable of catching output-input mismatches. primarily based on some of Aapo Tahkola's code. mesa-support_internal_driver_state_vars: Makes it possible for driver to define its own internal state parameters. Checked in. r300_fragment_wpos5: Adds fragment.position support, depends on the above patches. This patch doesn't apply cleanly to Mesa CVS head. r300_select_vertex_shader4.patch applies OK, but I'll hold off it until until the first one is resolved. -Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8243] X.org-7.1 and older locks up with radeon driver
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8243 --- Additional Comments From [EMAIL PROTECTED] 2006-11-17 09:18 --- (In reply to comment #4) I have almost the same problem with an X800 GTO, PCI-Express. Similar symptoms maybe... It has begun with recent kernels and xorg-7.x. Because the DRI didn't get enabled previously, right? Lockup after the same log line. It's the last line of server startup. This doesn't say anything beyond neither of these lockups occur immediately during initialization but probably at some point doing accelerated rendering. It doesn't mean it's the exact same problem, which is quite unlikely given the very different setups. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] fragment.position patch (RFC)
Brian Paul wrote: Rune Petersen wrote: Hi, I finally managed to iron out the last issue with getting a fully working fragment.position for the r300 driver. This should really require the big discussion if it wasn't for the fact that it depends on functional changes in r300_vertexprog.c (r300_select_vertex_shader4). The patches: r300_select_vertex_shader4: The patch makes the vertex program output from the fragment input. It makes the driver capable of catching output-input mismatches. primarily based on some of Aapo Tahkola's code. mesa-support_internal_driver_state_vars: Makes it possible for driver to define its own internal state parameters. Checked in. r300_fragment_wpos5: Adds fragment.position support, depends on the above patches. This patch doesn't apply cleanly to Mesa CVS head. r300_select_vertex_shader4.patch applies OK, but I'll hold off it until until the first one is resolved. I had to use diff to make the incremental patch. I may have made it wrong, but it applies cleanly if you do patch -p0 in the r300 directory. Anyway since you have checked the mesa patch, I have concerns committing the other to patches myself. Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
i915: Xserver crash and restart fails
Hi folks, I use the TV application MythTV that uses OpenGL to draw its GUI. Since a while I can crash my Xserver very easy just by switching to the workspace that shows the MythTV GUI. A restart of the Xserver fails. I have attached the log output. I use xserver-xorg-video-i810 1.7.2-1 (Debian Sid) and kernel 2.6.18.2. This is a Mac mini Core Duo with an i945G chipset. If you need more information, just ask. Kernel log: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 127 emitted: 130 Regards, Tino Xorg.0.log.gz Description: Binary data - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915: Xserver crash and restart fails
On Fri, Nov 17, 2006 at 22:12:09 +0100, Tino Keitel wrote: Hi folks, I use the TV application MythTV that uses OpenGL to draw its GUI. Since a while I can crash my Xserver very easy just by switching to the workspace that shows the MythTV GUI. A restart of the Xserver fails. I If this helps: I can stop the display manager, suspend to disk using suspend2, resume, and restart X. It seems to work again after this. Regards, Tino - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug #9032] Direct rendering applications hangs with tdfx-1.1.1, 1.2.0, 1.2.1, 1.2.2
Dear Alex, Thank you for the patch. It made the tdfx driver work again. Did you also announce version 1.2.3 package at http://lists.freedesktop.org/archives/xorg-announce/2006-November/ to be available at http://xorg.freedesktop.org/releases/individual/driver This would be very welcomed from all people having a txdfx card! Otherwise, since I'm running Debian I would submit a patch for the maintainers to make the driver work again (starting from 1.2.2) for Debian but not for other distribs. This would be suboptimal, the more upstream the better. Thanks, Svante Signell On Thu, 2006-11-16 at 00:19 +0100, Svante Signell wrote: On Wed, 2006-11-15 at 17:00 -0500, Alex Deucher wrote: On 11/15/06, Svante Signell [EMAIL PROTECTED] wrote: On Wed, 2006-11-15 at 15:02 -0500, Alex Deucher wrote: ... See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395044 for further information. Thanks, Sounds like a locking problem in the DDX. the locking stuff was cleaned up when AIGLX was merged and a lot of drivers broke (savage, mga, others?). See bug 6357 (savage) for reference. I suspect the fix should be pretty simple. I assume you mean the patch with id=7041, not 7035,7036. The savage patch had changes in savage_dri.c and savage_driver.h. The DRILock functions are called in both tdfx_accel.c and tdfx_driver.c as compared to savage_dri.c. Additionally TDFXDoBlockHandler and TDFXDoWakeupHandler are defined in tdfx_dri.c. Where to make the change? I thew together a quick and dirty untested patch: https://bugs.freedesktop.org/show_bug.cgi?id=9032 let me know if it works. Thanks a lot. It works with the patch! glxgears spins at 480 fps and other 3D applications do also work. Maybe you could release the updated driver as version 1.2.3 and also increment the TDFX_PATCHLEVEL to 3 in tdfx.h. (For 1.2.2 the patchlevel was not incremented, it is still reported as 1.2.1, and never announced). When the fixed driver has been released, I'll try to convince the Debian release managers to update the unstable package to this driver. Svante Alex - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Svante Signell [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
