Re: [R300] DRM perturbation
One question about tiling, will this cause any problems with the current r300 code? Or is it something completely unrelated? Well, Aapo has ported the patch and it worked on his computer - so it is unlikely to cause problems. If it does we are still better off finding and fixing the issue. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] DRM perturbation
Hopefully, the updated drm will allow me to stay in X for a while without encountering the "WaitForSomething(): select: errno=22" error I was having with the current drm. One question about tiling, will this cause any problems with the current r300 code? Or is it something completely unrelated? tiling is disabled by default on r3/4xx cards so it shouldn't affect you. someone needs to figure out how to properly enable it on r3/4xx cards (for both 2d and 3d). Once it is figured out it should provide a nice boost in performance. Alex, Could you explain to me what tiling is ? I thought it is simply a way to render images larger than 2048x2048, in which case I do not see how it can increase performance (ignoring things like cache sizes) There is a "TILING" register in R300 which we set, but I believe it refers to something different - partioning rendering into small squares (like 16x16) for the benefit of the rendering engine. thank you ! Vladimir Dergachev Alex Cheers, Ben Skeggs. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] DRM perturbation
On Mon, 28 Feb 2005 16:38:05 +1100, Ben Skeggs <[EMAIL PROTECTED]> wrote: > Vladimir Dergachev wrote: > > > [snip] > >Thus, could everyone with changing they have not committed yet to > > *DRM* driver but plan to please let me know ? Also any comments, > > reservations, etc. > > > >One reason I am so eager for this is that there have been quite a > > few fixes to the DRM driver, including tiling support. > > Sounds great to me. I've got nothing that changes the drm currently, > just been figuring out how the rest of the driver (everything except > vertex data emits) works. > > Hopefully, the updated drm will allow me to stay in X for a while > without encountering the > "WaitForSomething(): select: errno=22" error I was having with the > current drm. > > One question about tiling, will this cause any problems with the current > r300 code? Or is it > something completely unrelated? tiling is disabled by default on r3/4xx cards so it shouldn't affect you. someone needs to figure out how to properly enable it on r3/4xx cards (for both 2d and 3d). Once it is figured out it should provide a nice boost in performance. Alex > > Cheers, > Ben Skeggs. > > > > >best > > > > Vladimir Dergachev > > --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] DRM perturbation
Vladimir Dergachev wrote: [snip] Thus, could everyone with changing they have not committed yet to *DRM* driver but plan to please let me know ? Also any comments, reservations, etc. One reason I am so eager for this is that there have been quite a few fixes to the DRM driver, including tiling support. Sounds great to me. I've got nothing that changes the drm currently, just been figuring out how the rest of the driver (everything except vertex data emits) works. Hopefully, the updated drm will allow me to stay in X for a while without encountering the "WaitForSomething(): select: errno=22" error I was having with the current drm. One question about tiling, will this cause any problems with the current r300 code? Or is it something completely unrelated? Cheers, Ben Skeggs. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2241] implement GL_ARB_texture_cube_map in 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=2241 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #1981 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-02-27 16:56 --- Created an attachment (id=1986) --> (https://bugs.freedesktop.org/attachment.cgi?id=1986&action=view) mesa_radeon_cubemap_20050228.diff There was indeed some interaction with tiling, exactly the same as was with r200. The fixed BLIT_WIDTH y coord hack won't work. New fix, very quick testing shows the inner sphere is correct, but the outer box is completely wrong, unless sw tcl is used. btw I'm not sure why cube maps would be limited to 512x512, though if there were bugs with larger maps before, this was likely because of the same y coord hack (which could cause the y coord to exceed the limit of the blitter, the r200 driver had a workaround for that, though this is now gone with tiling since it's no longer needed). -- 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. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2625] New: quad strips are drawn in the wrong order on tcl-capable radeons
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=2625 Summary: quad strips are drawn in the wrong order on tcl-capable radeons Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] With tcl_mode!=0, Mesa/samples/prim exhibits a bug with quad strips (at the top right), the colors are switched compared to indirect rendering / sw tcl. AFAIK this is due to the quad strips (reduced to another primitive since the radeons don't support quads nor quad strips) being drawn in the wrong order. This is probably a bug somewhere in the tnl code, IIRC the r200 had the same bug before it was switched to use the native hw quads. -- 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. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] nasty bug found and fixed
Ok. I said that this bug doesnt exist and it was just my problem ... I changed my mind as it appeared again after rebuilding just about everything and tracked it down after long battle. This was caused by missing curly braces around texcoord VAP input configuration and resulted in all 8 texture units to be configured whenever vertex programs were used. However there is one thing I dont understand about this: How did badly configuring VAP input caused vertex programs to get broken when dummy var was added into struct r300_dma or struct r300_state ? AFAIK, even if textures would be enabled for no reason there should be enough checks in r300_setup_textures and other places not to cause bad pointers to read from there. There was a bug that could of caused this: #define ALLOC_STATE( ATOM, CHK, SZ, NM, IDX ) \ ... r300->hw.ATOM.cmd = (uint32_t*)CALLOC(SZ * sizeof(uint32_t)); \ ... caller: ALLOC_STATE( tex.filter, variable, mtu+1, "tex_filter", 0 ); result: r300->hw.ATOM.cmd = (uint32_t*)CALLOC(mtu+1 * sizeof(uint32_t)); \ This have been fixed some time ago though. Further more I modified verify_r300ResetHwState earlier to test that each state atom can actually hold all data its ment to hold, so these type of bugs should be gone. Could it be because R300_MAX_AOS_ARRAYS is only 8 whereas 9 would of needed ? Im not sure if trying to figure this out like this is worth the effort though as we can probably figure out any outstanding problems with textures by writing test programs. Some shots: http://nu.rasterburn.org/~aet/arbvptorus_1.png http://nu.rasterburn.org/~aet/arbvptorus_2.png -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] DRM perturbation
Hi all, Aapo Tahkola has made a merge of our current DRM driver and latest DRM driver from freedesktop.org. He asked me to commit this to R300 CVS (his Internet connection is a bit slow for this) and I would like to do it. There will be quite a few changes as the freedesktop.org + Aapo's patch will become the head and there would be an "orig" branch for unmodified freedesktop.org code. Thus, could everyone with changing they have not committed yet to *DRM* driver but plan to please let me know ? Also any comments, reservations, etc. One reason I am so eager for this is that there have been quite a few fixes to the DRM driver, including tiling support. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 - Saphire 9600
On Sun, 27 Feb 2005, Nicolai Haehnle wrote: On Sunday 27 February 2005 23:10, Hamie wrote: I've added in the pci-id's for the Saphire 9600 AGP card. As it has 2 pci-id's, I've added both to the pciids file, and added it into radeon_screen, but left the seocnd head commented out on radeon-screen.c as I'm unsiure whether or not it should be treeated separately... Why does it appear as two pci id's anyway? Can you treat it as a second card? To the best of my knowledge, we don't add the second head PCI ID to drm_pciids.txt because the driver only looks for the first PCI device (in fact, loading two driver instances, one for each device, would be certain to cause lockups). So please remove the second ID. I don't know why ATI decided to publish two PCI devices, and I don't have any related documentation. However, all the features like dual head can be used by only considering the first PCI device, as far as I know. The two PCI devices "feature" is needed for Windows 2000 which otherwise has no way to support dual head. best Vladimir Dergachev cu, Nicolai H --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2241] implement GL_ARB_texture_cube_map in 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=2241 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #1644 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-02-27 10:13 --- Created an attachment (id=1981) --> (https://bugs.freedesktop.org/attachment.cgi?id=1981&action=view) mesa_radeon_cubemap_20050227.diff patch against current mesa cvs. unfortunately textures are broken, might be some interaction with the texture-tiling patches. I might check that (much) later... @roland: thanks for committing the drm part. -- 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. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 - Saphire 9600
On Sunday 27 February 2005 23:10, Hamie wrote: > I've added in the pci-id's for the Saphire 9600 AGP card. As it has 2 > pci-id's, I've added both to the pciids file, and added it into > radeon_screen, but left the seocnd head commented out on radeon-screen.c > as I'm unsiure whether or not it should be treeated separately... > > Why does it appear as two pci id's anyway? Can you treat it as a second > card? To the best of my knowledge, we don't add the second head PCI ID to drm_pciids.txt because the driver only looks for the first PCI device (in fact, loading two driver instances, one for each device, would be certain to cause lockups). So please remove the second ID. I don't know why ATI decided to publish two PCI devices, and I don't have any related documentation. However, all the features like dual head can be used by only considering the first PCI device, as far as I know. cu, Nicolai > H pgpzXuX0ehPAX.pgp Description: PGP signature
[Bug 2241] implement GL_ARB_texture_cube_map in 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=2241 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #1643 is|0 |1 obsolete|| -- 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. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Radeon driver behaviour difference between R100 and R200
Hi, I am running the Linuxconsole.sf.net multiconsole extension on my machine and I have a Radeon 9200SE/AGP8x and a PCI Radeon7000VE. Both cards are driven hardware accelerated with DRI. I noticed behaviour differences running Tuxracer/PPracer between the two cards. E.g. on the Radeon 7000VE, the path that Tux makes in the snow with his belly is correctly drawn, but not on the Radeon9200SE. On the R9200, this path is mostly invisible (I guess it's drawn under the surface) but when Tux passes a hill and slides down on a steep slant, this path is drawn above the snowy surface, sometimes above Tux. And running either games on the R9200/AGP it eventually locks up the machine. With Tuxracer, the lockup is indeterministic, with PPracer one of the games' part, called "Ski jump" always locks up the machine hard at the same point, when Tux lands after his flight. Running these games on the R7000/PCI, the machine runs reliably. My system is FC3, I recently upgraded my official XOrg 6.8.1 to the Rawhide XOrg 6.8.2 RPM but it's still the same. Best regards, Zoltán Böszörményi --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 - Saphire 9600
I've added in the pci-id's for the Saphire 9600 AGP card. As it has 2 pci-id's, I've added both to the pciids file, and added it into radeon_screen, but left the seocnd head commented out on radeon-screen.c as I'm unsiure whether or not it should be treeated separately... Why does it appear as two pci id's anyway? Can you treat it as a second card? H --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
