[Bug 1615] New: R128 Software fallbacks broken
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://freedesktop.org/bugzilla/show_bug.cgi?id=1615 Summary: R128 Software fallbacks broken Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Drivers/DRI/r128 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Try setting no_rast=1 and running an app of your choice. Rendering will be wrong, and often followed by a hang. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Serious issues with Rage128 on PowerPC
On Wed, 2004-10-13 at 09:07 +1000, Benjamin Herrenschmidt wrote: > On Wed, 2004-10-13 at 00:41, Vladimir Dergachev wrote: > > > Just to check off the obvious, are you running a recent kernel with (I > > assume framebuffer) ? It could be that the default might have changed to > > configure the apertures to be bigendian. > > Changed ? The apertures have always been BE on PPC ... Maybe he meant the MMIO aperture, but again we've always used LE for that. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New R200 projtex patch
On Tue, 2004-10-12 at 15:18, Roland Scheidegger wrote: > Eric Anholt wrote: > > This one is nowhere near as thoroughly tested as previous ones. YMMV. > Certain textures in ut2k3/ut2k4 are still broken (all ground textures in > dm-antalus). Water reflection in the same map is also broken (this > worked in ut2k4 before (though I have some doubts the texcoords were > actually correct but it looked at least somewhat reasonable) but didn't > look correct in ut2k3). Don't have that map :( > DoomIII (as Adam already mentioned) has some serious errors, some levels > are completely dark due to "missing" textures. This is caused by the > TEX_PROC_CTL_2 stuff, removing that fixes it - I'm not sure, but I think > this register just doesn't do what we think it does. Maybe the > r200/rv250 just can't do mixed texgen/non-texgen, afterall I believe > this feature is not possible in D3D. New patch at: http://pdx.freedesktop.org/~anholt/dri/r200-projtex-8.diff This one makes texgenmix work except for the bottom left corner. The problem was that we were using the complete texgen matrix, even if it should only have been applied to specific coords. Fixed that by using rows of the identity matrix for set_texgen_matrix for disabled coords. Also, apparently q doesn't matter, so I removed the -1 for it. Also, I made GL_SPHERE_MAP a fallback since I never got texcyl to work otherwise. Does not fix doom3 lighting. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
What is driverSwapMethod = DRI_HIDE_X_CONTEXT?
While investigating rare Xserver (errno=22 in select) and X client (losing X connection) crashes that seem to be related to the new linux-core drm I found this in savage_dri.c and several other DDX drivers: ...driverSwapMethod = DRI_HIDE_X_CONTEXT; This seems to indicate that the Xserver is somehow involved in direct rendering buffer swap operations and the driver-independent DRI code installs a DRM signal handler for it. I changed it to DRI_KERNEL_SWAP in the savage driver and have not got any crashes since. I'm going to stress this system a bit more tomorrow. GL apps still work, as expected since in the savage driver the kernel is currently not involved in buffer swaps. It's all done client side. Can anybody tell me what DRI_HIDE_X_CONTEXT means exactly and why it's used in so many drivers? I could imagine it has something to do with page flipping in the radeon driver, but what about MGA for example? How does this influence the way the Xserver interacts with the DRM? I'm trying to understand why the changes in linux-core drm started causing Xserver hickups. Till now I'm lost in the Xserver's use of client connections' and device file handles. Thanks, Felix | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libGL cannot open savage_dri.so
On Wed, 13 Oct 2004 00:22:34 +0200 David <[EMAIL PROTECTED]> wrote: > I tried the 20041012 common+savage snapshots with the Xorg snapshots today. > The only problem I'm seeing is that direct rendering isn't enabled. > Xorg.0.log says that DRI is enabled. > > > Output of glxinfo with LIBGL_DEBUG=verbose: > name of display: :0.0 > libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) > libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so > libGL error: dlopen /usr/X11R6/lib/modules/dri/savage_dri.so failed (libexpat.so.1: > cannot open shared object file: No such file or directory) > libGL error: unable to find driver: savage_dri.so > display: :0 screen: 0 > direct rendering: No > ... I need to make sure that libexpat is compiled in statically. This was the case with the old XFree86-based snapshots. Somehow I must have screwed up with the new ones. Hang on, this should be fixed tomorrow or the day after. Until then try Alex's suggestion (symlink). [snip] Regards, Felix | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Serious issues with Rage128 on PowerPC
On Wed, 2004-10-13 at 00:41, Vladimir Dergachev wrote: > Just to check off the obvious, are you running a recent kernel with (I > assume framebuffer) ? It could be that the default might have changed to > configure the apertures to be bigendian. Changed ? The apertures have always been BE on PPC ... Ben. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libGL cannot open savage_dri.so
On Wed, 13 Oct 2004 00:22:34 +0200, David <[EMAIL PROTECTED]> wrote: > I tried the 20041012 common+savage snapshots with the Xorg snapshots today. > The only problem I'm seeing is that direct rendering isn't enabled. > Xorg.0.log says that DRI is enabled. > > Output of glxinfo with LIBGL_DEBUG=verbose: > name of display: :0.0 > libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) > libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so > libGL error: dlopen /usr/X11R6/lib/modules/dri/savage_dri.so failed (libexpat.so.1: > cannot open shared object file: No such file or directory) > libGL error: unable to find driver: savage_dri.so > display: :0 screen: 0 > direct rendering: No > ... > You need to create a link from libexpat.so.1 to libexpat.so Alex > ls -l /usr/X11R6/lib/modules/dri/savage_dri.so > -rwxr-xr-x 1 root root 5129761 2004-10-12 22:17 > /usr/X11R6/lib/modules/dri/savage_dri.so* > > Output of "xdriinfo options 0": > libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) > libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so > libGL error: dlopen /usr/X11R6/lib/modules/dri/savage_dri.so failed (libexpat.so.1: > cannot open shared object file: No such file or directory) > libGL error: unable to find driver: savage_dri.so > Driver "savage" is not installed or does not support configuration. > > A snip of dmesg: > ... > PCI: Unable to reserve mem region #2:[EMAIL PROTECTED] for device :01:00.0 > mtrr: base(0xda00) is not aligned on a size(0x500) boundary > [drm] Initialized savage 1.0.0 20011023 on minor 0: > [drm] Used old pci detect: framebuffer loaded > ... > > Regards, > David > --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
libGL cannot open savage_dri.so
I tried the 20041012 common+savage snapshots with the Xorg snapshots today. The only problem I'm seeing is that direct rendering isn't enabled. Xorg.0.log says that DRI is enabled. Output of glxinfo with LIBGL_DEBUG=verbose: name of display: :0.0 libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/savage_dri.so failed (libexpat.so.1: cannot open shared object file: No such file or directory) libGL error: unable to find driver: savage_dri.so display: :0 screen: 0 direct rendering: No ... ls -l /usr/X11R6/lib/modules/dri/savage_dri.so -rwxr-xr-x 1 root root 5129761 2004-10-12 22:17 /usr/X11R6/lib/modules/dri/savage_dri.so* Output of "xdriinfo options 0": libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/savage_dri.so failed (libexpat.so.1: cannot open shared object file: No such file or directory) libGL error: unable to find driver: savage_dri.so Driver "savage" is not installed or does not support configuration. A snip of dmesg: ... PCI: Unable to reserve mem region #2:[EMAIL PROTECTED] for device :01:00.0 mtrr: base(0xda00) is not aligned on a size(0x500) boundary [drm] Initialized savage 1.0.0 20011023 on minor 0: [drm] Used old pci detect: framebuffer loaded ... Regards, David --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
On Maw, 2004-10-12 at 01:14, Dave Airlie wrote: > application so it could modify them after validation if it was sufficently > sneaky enough... for the mach64 the idea was to allocate a pool of private > buffers using pci interfaces and use those to pass command streams after > verification.. the user app wouldn't be able to map these... Unless the data set is very large this is the right answer - just copy them. You can revoke pages but that is messy and involves cross CPU calls so sucks on SMP or HT machines. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New R200 projtex patch
Eric Anholt wrote: This one is nowhere near as thoroughly tested as previous ones. YMMV. Certain textures in ut2k3/ut2k4 are still broken (all ground textures in dm-antalus). Water reflection in the same map is also broken (this worked in ut2k4 before (though I have some doubts the texcoords were actually correct but it looked at least somewhat reasonable) but didn't look correct in ut2k3). DoomIII (as Adam already mentioned) has some serious errors, some levels are completely dark due to "missing" textures. This is caused by the TEX_PROC_CTL_2 stuff, removing that fixes it - I'm not sure, but I think this register just doesn't do what we think it does. Maybe the r200/rv250 just can't do mixed texgen/non-texgen, afterall I believe this feature is not possible in D3D. Roland --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Serious issues with Rage128 on PowerPC
Am 2004.10.12 18:38:18 +0200 schrieb(en) Ian Romanick:
> Andreas Stenglein wrote:
>
> > It might be unrelated (and just some other silly mistake/problem):
> > Using my local version of radeon (r100) driver converted to "t_vertex"
> > I discovered a similar problem recently.
> > 1) running glxgears I get the "hang with only mousepointer moving" -> reboot
> > needed.
>
> I get the hang, but I can ssh in and kill gears. Did you see these
> problems on x86 or PowerPC?
Its on x86 / Athlon XP with Radeon 7500, gcc 2.95.3
(I added some brackets{} in the dma-templates so it compiles)
I can ssh in and kill it, but its not possible to "revive" the box, I have to switch
off.
It might work with the soft-reset trick used for debugging r300.
> > 2) setting tcl_mode=0 and running glxgears -> instant reboot
> > 3) other software seems to work fine, for example q3 or the projtex test.
> > 4) running glxgears with the "original" driver from mesa-cvs works.
>
> I got the same hang with progs/demos/readpix. I tested with gears to
> make sure my changes weren't causing the problem.
Im going to try it (later)...
best regards,
Andreas
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220 --- Additional Comments From [EMAIL PROTECTED] 2004-10-12 12:33 --- (In reply to comment #28) I think it's XORG-6_8-branch. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: README files invisible on http://freedesktop.org
On Tue, 12 Oct 2004, Felix [ISO-8859-1] Kühling wrote: > Is there something in the httpd configuration that makes README files > invisible in directory listings? Why would anyone want to hide README > files? Yes, it is normal in default Apache HTTP configuration. See: # ReadmeName is the name of the README file the server will look for by # default, and append to directory listings. # # HeaderName is the name of a file which should be prepended to # directory indexes. ReadmeName README.html HeaderName HEADER.html # # IndexIgnore is a set of filenames which directory indexing should ignore # and not include in the listing. Shell-style wildcarding is permitted. # IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t Probably the IndexIgnore needs to be fixed. (I had same problem on one of my servers.) Jeremy C. Reed BSD News, BSD tutorials, BSD links http://www.bsdnewsletter.com/ --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 ReadPixels optimization
Dieter Nützel wrote: NONE of your three versions gave me direct rendering?! I've tested with and without your TLS-patch (progress?). The symbols are in. DRI-Mesa/Patches> nm /usr/X11R6-NO-TLS/lib/modules/dri/r200_dri.so | grep r200ReadRGBASpan_ARGB 00175714 t r200ReadRGBASpan_ARGB 00175be4 t r200ReadRGBASpan_ARGB_MMX 00175ad4 t r200ReadRGBASpan_ARGB_SSE 001759c4 t r200ReadRGBASpan_ARGB_SSE2 But DRI-Mesa/Patches> nm /usr/X11R6-NO-TLS/lib/modules/dri/r200_dri.so | grep _generic_read_RGBA_span_BGRA U _generic_read_RGBA_span_BGRA_REV_MMX U _generic_read_RGBA_span_BGRA_REV_SSE U _generic_read_RGBA_span_BGRA_REV_SSE2 I'm on XFree86 DRI CVS build as long as my distro based on it;-) You'll have to update the Imakefiles to build in DRI CVS. The problem is that it's not linking (or compiling) ../common/read_rgba_span_x86.o. BTW The old indirect mode is way faster then direct for me: It should be several orders of magnitude faster. Afterall, it's actually just doing a memory-to-memory copy instead of reading from the framebuffer. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
Hi, Ian! Ian Romanick wrote: Thomas Hellström wrote: Also, the people on the unichrome site including me are totally lost when it comes to 3D, and you'll need a quite detailed documentation to fix things up. I guess the 3D command verification will be quite some work. The best would be to convince VIA that they would very much benefit from having a secure DRI, and have them do it in an open source framework. I don't think that's entirely true. I'm not too familiar with this part of the Unichrome DRI driver, but you basically want to be able to send buffers of register / value pairs into the kernel for verification, right? If so, I don't think the changes will be that difficult, though they may be time consuming. On the user side, we just need a mechanism to fill & submit the buffers. The tricky part is finding all the places that currently access the MMIO region, though that probably won't be too difficult. On the kernel side, we just have to verify those buffers. No detailed 3D knowledge is needed for that. A person can just look at the DRI driver to see what kinds of things it sends! :) Can you make it to the #dri-devel chat next Monday? Perhaps we could discuss the details then. I'll try to do that. Upon closer inspection of the unichrome_dri.so driver source it seems like there is a PCI path that takes a command buffer and parses it, and this should be an excellent start of the command verifier. According to Erdi, the driver currently alternates between two static AGP buffers. To port this to use the ring-buffers one would probably only need to malloc() memory for those and replace the current flush code with an IOCTL. The problem for me is, like for most people, time. Regards. Thomas --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-deve l --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Linux: 2.4.28-pre4, No More New Features For 2.4
On Tue, 12 Oct 2004 09:40:36 -0700, Ian Romanick <[EMAIL PROTECTED]> wrote: > Given that, it seems reasonable to not implement drm-core for 2.4. If > we need to apply bug fixes to 2.4, we'll just have to figure out how to > back-port them to the old arch. Backporting shouldn't be too hard since the card specific code is mostly untouched, it's the base driver code that is completely changed. If we only backport fixes and not new features the work should be minimal. Is drm-core good enough for the kernel yet? Are more than five people using it? At some point we need to bless DRM core as the 2.6 platform. After that happens I'll remove all of the 2.4 compatibility hooks from it. Those hooks generate considerable clutter in the code. I could also remove the linux-2.6 directory from CVS which will force all 2.6 CVS users onto the drm-core code. That would create some more testers. What is the decision for BSD? Is it going to track drm-core or stay with the old model? If it stays with the old model it will have to use the 2.4 shared files. The DRM() macros are gone in the shared-core directory so the only way to use that code is for BSD to also use the core model. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
Thomas Hellström wrote: Also, the people on the unichrome site including me are totally lost when it comes to 3D, and you'll need a quite detailed documentation to fix things up. I guess the 3D command verification will be quite some work. The best would be to convince VIA that they would very much benefit from having a secure DRI, and have them do it in an open source framework. I don't think that's entirely true. I'm not too familiar with this part of the Unichrome DRI driver, but you basically want to be able to send buffers of register / value pairs into the kernel for verification, right? If so, I don't think the changes will be that difficult, though they may be time consuming. On the user side, we just need a mechanism to fill & submit the buffers. The tricky part is finding all the places that currently access the MMIO region, though that probably won't be too difficult. On the kernel side, we just have to verify those buffers. No detailed 3D knowledge is needed for that. A person can just look at the DRI driver to see what kinds of things it sends! :) Can you make it to the #dri-devel chat next Monday? Perhaps we could discuss the details then. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Serious issues with Rage128 on PowerPC
On Tue, 2004-10-12 at 08:36, Ian Romanick wrote: > It's a stock AGP G4. The card is the original Rage128. The kernel is > the debian 2.6.8-powerpc kernel (dittor for DRM), and X is yesterday's > X.org. The last time I did anything with that machine was about a month > ago with a 2.4.25 kernel (and whatever X.org was current then), and it > worked fine. I suspect the problems are caused by recent changes to the > 3D driver. > > Regular X stuff works fine. It seems present in xorg 6.8.0 according to https://freedesktop.org/bugzilla/show_bug.cgi?id=1513, so older than that. -- Donnie Berkholz Gentoo Linux --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1374] No Xinerama possible with the 2 outputs of ATI Radeon 9600
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://freedesktop.org/bugzilla/show_bug.cgi?id=1374 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Component|General |Driver/Radeon Product|DRI |xorg Resolution||DUPLICATE Version|DRI CVS |CVS_head --- Additional Comments From [EMAIL PROTECTED] 2004-10-12 09:48 --- this is a DDX problem. *** This bug has been marked as a duplicate of 1559 *** -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Linux: 2.4.28-pre4, No More New Features For 2.4
Jon Smirl wrote: http://kerneltrap.org/node/view/3980 Marcelo Tosatti [interview] released 2.4.28-pre4 with few changes since -pre3 a month ago [story], "it contains a number of driver updates (pcnet, e1000, gdth, prism54), a network update from David, few more gcc3.4 warning fixes." He noted that no more new features are planned for the 2.4 stable kernel, "from now on [I] can change only what is necessary and let the 2.4 tree [rest] in peace :)" What should be our policy toward 2.4? For example if 2.4 is now closed should we implement the drm-core model for it? What about new drivers? If 2.4 is closed these aren't going to be accepted. This is a different question than fixing the drivers that are already in 2.4. We should still do that as we find problems. Given that, it seems reasonable to not implement drm-core for 2.4. If we need to apply bug fixes to 2.4, we'll just have to figure out how to back-port them to the old arch. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Serious issues with Rage128 on PowerPC
Andreas Stenglein wrote: It might be unrelated (and just some other silly mistake/problem): Using my local version of radeon (r100) driver converted to "t_vertex" I discovered a similar problem recently. 1) running glxgears I get the "hang with only mousepointer moving" -> reboot needed. I get the hang, but I can ssh in and kill gears. Did you see these problems on x86 or PowerPC? 2) setting tcl_mode=0 and running glxgears -> instant reboot 3) other software seems to work fine, for example q3 or the projtex test. 4) running glxgears with the "original" driver from mesa-cvs works. I got the same hang with progs/demos/readpix. I tested with gears to make sure my changes weren't causing the problem. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Serious issues with Rage128 on PowerPC
Michel DÃnzer wrote: On Mon, 2004-10-11 at 18:37 -0700, Ian Romanick wrote: I was trying to test the latest version of my ReadPixels work to make sure I didn't break anything on big-endian. However, it seems someone beat me to it in the Rage128 driver. :) In a nutshell, I can get one frame of gears, and then the 3D engine is toast. After that frame is drawn, gears is at 100% and X is unresponsive. When I kill gears, everything goes back to semi-normal. If I run another 3D program, I get an empty (just a frame!) window. Looking at the output from R128_DEBUG=all, it appears to be stuck in r128EmitHwStateLocked. Please provide a little more context - machine type (G4 I guess? Which model exactly?), AGP/PCI, versions of kernel/DRM/X, ... It's a stock AGP G4. The card is the original Rage128. The kernel is the debian 2.6.8-powerpc kernel (dittor for DRM), and X is yesterday's X.org. The last time I did anything with that machine was about a month ago with a 2.4.25 kernel (and whatever X.org was current then), and it worked fine. I suspect the problems are caused by recent changes to the 3D driver. Regular X stuff works fine. That single frame of gears is also wrong. The colors are pinks and purples. I suspect this may just be a byte-ordering problem. I notice that the driver wants to use BGRA for primary color, but I suspect the hardware really wants ARGB. Ditto for secondary color / fog. Yeah, there are endianness issues to work out in t_vertex. :( If I can get the driver to not wedge, I'll start working on those. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New R200 projtex patch
On Tuesday 12 October 2004 04:04, Eric Anholt wrote: > New patch is at > http://pdx.freedesktop.org/~anholt/dri/r200-projtex-7.diff > > This one is nowhere near as thoroughly tested as previous ones. YMMV. This cleans up doom3 in hwtcl quite a bit. Lighting is still messed up though. Lights you can interact with (flashlight, some of the fluorescents) seem to have a dead zone, I can shine the flashlight on the wall and not see anything until I back up. Both quake3 and ut look good though, so it can't be too wrong. - ajax pgpdv7A62S5A3.pgp Description: PGP signature
README files invisible on http://freedesktop.org
I just wanted to add a README.Xorg in http://freedesktop.org/~dri/snapshots/extras when I noticed that there are two older README.* files which do not show up in http. A new README.Xorg didn't show up either. However adding an empty file with a different name (I tried `touch xorgstuff`) was reflected on http. Is there something in the httpd configuration that makes README files invisible in directory listings? Why would anyone want to hide README files? Regards, Felix | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Serious issues with Rage128 on PowerPC
On Mon, 11 Oct 2004, Ian Romanick wrote: I was trying to test the latest version of my ReadPixels work to make sure I didn't break anything on big-endian. However, it seems someone beat me to it in the Rage128 driver. :) In a nutshell, I can get one frame of gears, and then the 3D engine is toast. After that frame is drawn, gears is at 100% and X is unresponsive. When I kill gears, everything goes back to semi-normal. If I run another 3D program, I get an empty (just a frame!) window. Looking at the output from R128_DEBUG=all, it appears to be stuck in r128EmitHwStateLocked. That single frame of gears is also wrong. The colors are pinks and purples. I suspect this may just be a byte-ordering problem. I notice that the driver wants to use BGRA for primary color, but I suspect the hardware really wants ARGB. Ditto for secondary color / fog. Just to check off the obvious, are you running a recent kernel with (I assume framebuffer) ? It could be that the default might have changed to configure the apertures to be bigendian. Of course, I have no idea, but this would be one of the "easy" things to check. best Vladimir Dergachev --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Undefined symbols in recent DRM
El Martes, 12 de Octubre del 2004 1:02 AM, Felix Kühling escribió: > I've uploaded a Xorg-modules.tar.bz2 to the snapshots/extras dir. It > contains all (strip -g) modules except the ones included in the binary > snapshots (libGLcore.a, libglx.a, libdri.a, all 2D and 3D drivers). > David, could you give it a try? Proceed as follows: > > > cd /usr/X11R6/lib > mv modules modules.backup > tar -tjf ~/Xorg-modules.tar.bz2 > > > If this works I'll update the snapshot installation instructions and add > a README.Xorg in the extras dir. > > Regards, > Felix Yes, it works. Finally I can continue testing. However "tar -tjf" only lists the archive contents ;) but I got the idea. You can update the docs. Thanks (to all) for your work. David. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
drm:add video memory as DMA buffer
Because some chips(at least s3 DeltaChrome) can't use system memory as DMA buffer(or vertex buffer),for pci card,we use video memory as dma/vertex buffer. Then whether is it reasonable to add a function like drm_addbufs_fb in linux-core/drm_bufs.c? Thanks! Austin --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
New R200 projtex patch
New patch is at http://pdx.freedesktop.org/~anholt/dri/r200-projtex-7.diff New in this one is reenabling vtxfmt (avoiding the crash on exit of many apps), making vtxfmt work in texgenmix, fixing the fog/specular EMIT_ATTR issue (like was done for savage) for r200, and cleaning a warning. The problem was that vtxfmt was dropping coords submitted beyond those that get used by the texture type. The problem with this is that a texture coordinate matrix can shuffle values around, so that that "r" coord on your 2d texture can matter. If we cared (do we?) we could make the fallback dependent on whether there were active matrices. The newer version is probably less efficient than the older one due to sending all of those texcoord functions through one multitexcoord equivalent instead of "unrolling," but it seems like little ends up going through vtxfmt anyway. This one is nowhere near as thoroughly tested as previous ones. YMMV. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
