[Bug 1678] IGP 320M
http://bugs.freedesktop.org/show_bug.cgi?id=1678 Behdad Esfahbod <[EMAIL PROTECTED]> changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 9969] Heavy MGA DRI use causes Xorg lock
http://bugs.freedesktop.org/show_bug.cgi?id=9969 Daniel Stone <[EMAIL PROTECTED]> changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 9969] Heavy MGA DRI use causes Xorg lock
http://bugs.freedesktop.org/show_bug.cgi?id=9969 balajiv <[EMAIL PROTECTED]> changed: What|Removed |Added AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1678] IGP 320M
http://bugs.freedesktop.org/show_bug.cgi?id=1678 balajiv <[EMAIL PROTECTED]> changed: What|Removed |Added AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15195] [i915 i965 packed_depth_stencil] glean case depthStencil failed
http://bugs.freedesktop.org/show_bug.cgi?id=15195 Gordon Jin <[EMAIL PROTECTED]> changed: What|Removed |Added CC||dri- ||[EMAIL PROTECTED] AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- 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. You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15380] [i915 i965 FBO] glFramebufferTexture2D Segmentation fault in some case
http://bugs.freedesktop.org/show_bug.cgi?id=15380 Gordon Jin <[EMAIL PROTECTED]> changed: What|Removed |Added CC||dri- ||[EMAIL PROTECTED] AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- 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. You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15400] [915]mesa demo 'shadowtex 'run failed
http://bugs.freedesktop.org/show_bug.cgi?id=15400 Gordon Jin <[EMAIL PROTECTED]> changed: What|Removed |Added CC||dri- ||[EMAIL PROTECTED] AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- 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. You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15527] 3D application 'doom3' run abort
http://bugs.freedesktop.org/show_bug.cgi?id=15527 Gordon Jin <[EMAIL PROTECTED]> changed: What|Removed |Added CC||dri- ||[EMAIL PROTECTED] AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- 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. You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15480] r200 vertex program regression
http://bugs.freedesktop.org/show_bug.cgi?id=15480 Roland Scheidegger <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Roland Scheidegger <[EMAIL PROTECTED]> 2008-04-16 17:56:54 PST --- Thanks for the patch, applied. Closing since the other issue looks completely unrelated. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-users] 3DMark2001SE (Single texturing-fill rate test)
On Wed, 16 Apr 2008 05:23:16 -0700 (PDT) smoki <[EMAIL PROTECTED]> wrote: > > This screenshots is from 3DMark2001SE (Single texturing-fill rate test) > runing in wine-0.9.59 using r200 driver on Linux. > > First is WRONG using hw pipeline. > > http://www.nabble.com/file/p16721263/wine_hw.jpeg > > Second is CORRECT using sw pipeline. > > http://www.nabble.com/file/p16721263/wine_sw.jpeg > > Problem is in the r200 driver, OK:)? > -- Adding CCs :) khaqq - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-users] Doom3- false texturing on mirror
khaqq wrote: > On Wed, 16 Apr 2008 04:34:17 -0700 (PDT) > smoki <[EMAIL PROTECTED]> wrote: > >> This is happen in r200 driver, because when i use software TCL pipeline it's >> correct. >> Is there anybody who can handle this? In what level was that? Roland - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Writing a state tracker for Gallium3D/SoftPipe
There are three components that you'll need: - state tracker -- which is API dependent - hw driver -- HW dependent (softpipe is an example), which implements the p_context.h interface. - winsys -- which is dependent on API, HW, OS, etc. The winsys is basically the glue that holds it all together. The intention is for it to be as small as possible and over time we'll improve the concept & help make it smaller still. In Mesa/Gallium/DRI drivers, the winsys is the only component with an overall view of the structure of the driver, all the other components see only one aspect of it, but the Winsys is what puts all the pieces together, and provides the glue/services code to make it all work. At minimum, the winsys will implement the interface in p_winsys.h, which provides surface/buffer management functions to both the state tracker and hardware driver. In addition, the HW drivers each propose a command submission interface which is specific to the particular piece of hardware. As the winsys currently implements both these interfaces, it by definition becomes hardware specific -- though internally there is usually a separation between these pieces. Regarding the AUB stuff in the Xlib winsys, yes you can ignore that. It's a hack to get a simulator running without hardware - at some point I'll try and restructure things to make that clearer. What I'm guessing you want to know is how to break things down in your proposed state tracker. The overriding principle is to put as little in the winsys as possible. At first, it's clear that anything in p_winsys.h must be done in the winsys, similarly for whatever functionality the hw driver requests in it's backend interface - eg softpipe/sp_winsys.h. Beyond that, the winsys needs to implement some sort of 'create_screen' and 'create_context' functionality, but would ideally hand off as much as possible after that to shared code in the state tracker or HW driver. What's missing to some extent from the gallium interfaces is a fully-developed device/screen/global entity. Much of the work so far has been around the per-context entity (pipe_context), but the per-screen component that does surface management, etc, has been less well developed. That will change over time, but for the moment there's more of it in the winsys than I'd like. Keith - Original Message > From: Younes M <[EMAIL PROTECTED]> > To: dri-devel@lists.sourceforge.net > Sent: Wednesday, April 16, 2008 6:47:48 PM > Subject: Writing a state tracker for Gallium3D/SoftPipe > > I'm trying to get up and running writing a state tracker for libXvMC > using SoftPipe, but looking at the Mesa src a few things are unclear > to me. > > Looking at root/src/gallium/winsys/xlib I can't quite figure out where > Mesa ends and where Gallium starts. It's my understanding that the > winsys creates the pipe_context that I need, but is there a generic X > winsys driver? The xm_* sources where softpipe_create() is eventually > called (in xm_winsys.c) look very tied to Mesa, even though they > appear to be in a generic directory, so do all state trackers have to > implement something similar to use SoftPipe? Is this also the case for > using hw drivers? Looking at the the aub src files and the dri > directory it looks like that stuff is tied to the hw and does not have > to be provided for each state tracker. > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-users] Doom3- false texturing on mirror
On Wed, 16 Apr 2008 04:34:17 -0700 (PDT) smoki <[EMAIL PROTECTED]> wrote: > > This is happen in r200 driver, because when i use software TCL pipeline it's > correct. > Is there anybody who can handle this? Adding CCs. khaqq - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Writing a state tracker for Gallium3D/SoftPipe
I'm trying to get up and running writing a state tracker for libXvMC using SoftPipe, but looking at the Mesa src a few things are unclear to me. Looking at root/src/gallium/winsys/xlib I can't quite figure out where Mesa ends and where Gallium starts. It's my understanding that the winsys creates the pipe_context that I need, but is there a generic X winsys driver? The xm_* sources where softpipe_create() is eventually called (in xm_winsys.c) look very tied to Mesa, even though they appear to be in a generic directory, so do all state trackers have to implement something similar to use SoftPipe? Is this also the case for using hw drivers? Looking at the the aub src files and the dri directory it looks like that stuff is tied to the hw and does not have to be provided for each state tracker. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Testing DRI on ATI Radeon Xpress 200M IGP (5975)
Ludovic Brenta wrote: > Hello, > > Tonight I finally took the time to enable DRI on my laptop. I > understand that support for my particular chipset is experimental and > currently "needs more testing on differing models", and I hereby offer > help for testing. > > DRI appears to work and glxgears says: > Warning, xpress200 detected. > 2066 frames in 5.0 seconds = 413.009 FPS > 2078 frames in 5.0 seconds = 415.508 FPS > 2066 frames in 5.0 seconds = 413.098 FPS > 2070 frames in 5.0 seconds = 413.984 FPS > 2099 frames in 5.0 seconds = 419.766 FPS > > I would like to know if there is a particular area of the driver, or a > particular feature of the chipset, that needs testing. What can I do > to help? > > I can't comment on particular feature/dirver area, just how to test in general. Test results are most valuable against current git. Have a look at http://wiki.x.org/wiki/Development/git how to compile/install/run xorg/drm/mesa/xf86-video-ati from git sources. Then take your favorite OpenGL apps and watch out for errors. If you found some errors in git, compare it with dri from debian and perhaps with fglrx. If something works with debian/unstable but not git, you can bisect to find which patch caused a regression. And of course report any found bugs. Markus - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: fake bufmgr and aperture sizing.
Dave Airlie wrote: >> At least for TTM this is part of a larger problem where you can hit >> problems both when the pinned page quota is hit, and when >> you can't fit an object in the aperture. >> >> The other problem is the one you mention. Since we're dealing with >> multiple clients and only evict one buffer at a time at aperture >> space-shortage and even may have pinned buffers scattered in the >> aperture, there is a probability that the execbuf call will fail with >> -ENOMEM. I guess before doing that, the kernel could retry and evict all >> evictable buffers before starting validation. That would eliminate all >> fragmentation issues except those arising from pinned buffers. >> >> > > IMHO with a complete kernel driver we can avoid fragmentation issues with > a cost, i.e. if only the kernel can pin buffers (scanout/cursor etc) we > should be able to fence and move them by having special pinned move > handlers that would only be used in extreme situations, these handlers > would know how to turn cursors off and even move the display base address, > it may have to flicker the screen but really anything is better than > failing due to fragged memory. > I agree. It's probably possible to come up with a clever scheme for this, and even to update the display base address during vblank. User space doesn't need to care, since the virtual address will stay the same, but in the end we need to do something about locking in the fb layer. We need to be able to modify the kernel virtual address and GPU offset while fb is running. >> The problem remains how to avoid this situation completely. I guess the >> drm driver can reserve a global "safe" aperture size, and communicate >> that to the 3D client, but the current TTM drivers don't deal with this >> situation. >> My first idea would probably be your first alternative. Flush and re-do >> the state-emit if the combined buffer size is larger than the "safe" >> aperture size. >> > > I think a dynamically sized safe aperture size that can be used per batch > submission, is probably the best plan, this might also allow throttling in > multi-app situations to help avoid thrashing, by reducing the per-app > limits. For cards with per-process we could make it the size of the > per-process aperture. > Actually, thrashing TT memory shouldn't be that horribly bad, as there is generally no caching attribute flipping going on, but it will temporarily stall the driver from working ahead with a new batch and thus drain the pipeline. Thrashing will go on anyway in the multi-app situation, since the driver needs to throttle due to an aperture space shortage, but it will be more driver-induced and perhaps a bit more efficient. > The case where an app manages to submit a working set for a single > operation that is larger than the GPU can deal with, should be considered > a bug in the driver I suppose. > Yes, I agree, but we must make sure the kernel can _really_ honor the advertized working set size, because otherwise it's an OOM situation we can't recover from other than by perhaps skipping a frame. This is increasingly important with binning hardware that likes to submit a whole scene in a single batch, but OTOH they usually have a very large aperture / GPU virtual space. > Dave. > /Thomas - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: fake bufmgr and aperture sizing.
> > The problem remains how to avoid this situation completely. I guess the > > drm driver can reserve a global "safe" aperture size, and communicate > > that to the 3D client, but the current TTM drivers don't deal with this > > situation. > > My first idea would probably be your first alternative. Flush and re-do > > the state-emit if the combined buffer size is larger than the "safe" > > aperture size. > > I think a dynamically sized safe aperture size that can be used per batch > submission, is probably the best plan, this might also allow throttling in > multi-app situations to help avoid thrashing, by reducing the per-app > limits. For cards with per-process we could make it the size of the > per-process aperture. > > The case where an app manages to submit a working set for a single > operation that is larger than the GPU can deal with, should be considered > a bug in the driver I suppose. The trouble with the safe limit is that it can change in a timeframe that is inconvenient for the driver -- ie, if it changes when a driver has already constructed most of a scene, what happens? This is a lot like the old cliprect problem, where driver choices can be invalidated later on, leaving it in a difficult position. Trying to chop an already-constructed command stream up after the fact is unappealing, even on simple architectures like the i915 in classic mode. Add zone rendering or some other wrinkle & it looses appeal fast. What about two limits -- hard & soft? If the "hard" limit can avoid changing, that makes things a lot nicer for the driver. When the soft one changes, the driver can respect that next frame, but submit the current command stream as is. Keith - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: fake bufmgr and aperture sizing.
> At least for TTM this is part of a larger problem where you can hit > problems both when the pinned page quota is hit, and when > you can't fit an object in the aperture. > > The other problem is the one you mention. Since we're dealing with > multiple clients and only evict one buffer at a time at aperture > space-shortage and even may have pinned buffers scattered in the > aperture, there is a probability that the execbuf call will fail with > -ENOMEM. I guess before doing that, the kernel could retry and evict all > evictable buffers before starting validation. That would eliminate all > fragmentation issues except those arising from pinned buffers. > IMHO with a complete kernel driver we can avoid fragmentation issues with a cost, i.e. if only the kernel can pin buffers (scanout/cursor etc) we should be able to fence and move them by having special pinned move handlers that would only be used in extreme situations, these handlers would know how to turn cursors off and even move the display base address, it may have to flicker the screen but really anything is better than failing due to fragged memory. > The problem remains how to avoid this situation completely. I guess the > drm driver can reserve a global "safe" aperture size, and communicate > that to the 3D client, but the current TTM drivers don't deal with this > situation. > My first idea would probably be your first alternative. Flush and re-do > the state-emit if the combined buffer size is larger than the "safe" > aperture size. I think a dynamically sized safe aperture size that can be used per batch submission, is probably the best plan, this might also allow throttling in multi-app situations to help avoid thrashing, by reducing the per-app limits. For cards with per-process we could make it the size of the per-process aperture. The case where an app manages to submit a working set for a single operation that is larger than the GPU can deal with, should be considered a bug in the driver I suppose. Dave. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Testing DRI on ATI Radeon Xpress 200M IGP (5975)
Hello, Tonight I finally took the time to enable DRI on my laptop. I understand that support for my particular chipset is experimental and currently "needs more testing on differing models", and I hereby offer help for testing. DRI appears to work and glxgears says: Warning, xpress200 detected. 2066 frames in 5.0 seconds = 413.009 FPS 2078 frames in 5.0 seconds = 415.508 FPS 2066 frames in 5.0 seconds = 413.098 FPS 2070 frames in 5.0 seconds = 413.984 FPS 2099 frames in 5.0 seconds = 419.766 FPS I would like to know if there is a particular area of the driver, or a particular feature of the chipset, that needs testing. What can I do to help? lspci -nn says: 00:00.0 Host bridge [0600]: ATI Technologies Inc RS480 Host Bridge [1002:5950] (rev 10) 00:01.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a3f] 00:06.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a38] 00:12.0 IDE interface [0101]: ATI Technologies Inc IXP SB400 Serial ATA Controller [1002:4379] (rev 80) 00:13.0 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB Host Controller [1002:4374] (rev 80) 00:13.1 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB Host Controller [1002:4375] (rev 80) 00:13.2 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB2 Host Controller [1002:4373] (rev 80) 00:14.0 SMBus [0c05]: ATI Technologies Inc IXP SB400 SMBus Controller [1002:4372] (rev 81) 00:14.1 IDE interface [0101]: ATI Technologies Inc IXP SB400 IDE Controller [1002:4376] (rev 80) 00:14.2 Audio device [0403]: ATI Technologies Inc IXP SB4x0 High Definition Audio Controller [1002:437b] (rev 01) 00:14.3 ISA bridge [0601]: ATI Technologies Inc IXP SB400 PCI-ISA Bridge [1002:4377] (rev 80) 00:14.4 PCI bridge [0604]: ATI Technologies Inc IXP SB400 PCI-PCI Bridge [1002:4371] (rev 80) 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS485 [Radeon Xpress 1100 IGP] [1002:5975] 02:01.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet [14e4:169c] (rev 03) 02:04.0 CardBus bridge [0607]: Texas Instruments PCIxx12 Cardbus Controller [104c:8039] 30:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11a/b/g [14e4:4312] (rev 01) My laptop is a HP Compaq nx6325 with AMD Turion TL-60 (dual-core, 2 GHz) with 2 GiB RAM, running Debian GNU/Linux testing/unstable with the following relevant packages: ii linux-image-2.6.24-1-amd642.6.24-5 Linux 2.6.24 image on AMD64 ii xserver-xorg 1:7.3+10 the X.Org X server ii xserver-xorg-core 2:1.4.1~git20080131-3 Xorg X server - core server ii xserver-xorg-input-kbd1:1.2.2-3 X.Org X server -- keyboard input driver ii xserver-xorg-input-mouse 1:1.2.3-2 X.Org X server -- mouse input driver ii xserver-xorg-input-synaptics 0.14.7~git20070706-2 Synaptics TouchPad driver for X.Org/XFree86 ii xserver-xorg-video-ati1:6.8.0-1 X.Org X server -- ATI display driver ii freeglut3 2.4.0-6 OpenGL Utility Toolkit ii libgl1-mesa-dev 7.0.3~rc2-2 A free implementation of the OpenGL API -- G ii libgl1-mesa-dri 7.0.3~rc2-2 A free implementation of the OpenGL API -- D ii libgl1-mesa-glx 7.0.3~rc2-2 A free implementation of the OpenGL API -- G ii libglu1-mesa 7.0.3~rc2-2 The OpenGL utility library (GLU) ii libglu1-mesa-dev 7.0.3~rc2-2 The OpenGL utility library -- development fi ii mesa-common-dev 7.0.3~rc2-2 Developer documentation for Mesa ii mesa-utils7.0.3~rc2-2 Miscellaneous Mesa GL utilities -- Ludovic Brenta. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
