[Bug 22743] nexuiz game: missing weapons and enemies models
http://bugs.freedesktop.org/show_bug.cgi?id=22743 --- Comment #1 from Andre Maasikas amaasi...@gmail.com 2009-08-12 23:48:44 PST --- Seems it fails the max_index check in drawrangeelements when rendering player models. e.g: Mesa warning: glDraw[Range]Elements(start 0, end 126, count 240, type 0x1403, indices=(nil)) index=126 is out of bounds (max=125) Element Buffer 85 (size 480) Mesa warning: glDraw[Range]Elements(start 6, end 1495, count 5130, type 0x1403, indices=0xfad0ac4) index=1495 is out of bounds (max=1494) Element Buffer 0 (size 0) You can try if commenting out the return statement in this check or inside the game using gldrawelements fixes it (open console shift-ESC type: gl_mesh_drawrangeelements 0). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm sysfs questions
Kristian Høgsberg wrote:
2009/8/11 Thomas Hellström tho...@shipmail.org:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org wrote:
Hi!
I'm wondering why we are using a struct device as a sysfs
representation for connectors instead of a struct kobject?
In particular, what stops the drm_sysfs_[suspend|resume] functions to
get called for the connectors, having them cast to a struct drm_minor
and sending the cpu to the bushes?
Hm, maybe we're just getting lucky that the drm minor check fails for
everything but the DRM core device.
Yes, I think that's actually the case.
kobjects might make sense to move
to, unless we can think of other things we'd like to do with a full
device (e.g. runtime power management or some sort of per-connector
suspend/resume).
I can't really think of a case where the device owning the connector
can't handle this?
But we'd lose the /sys/drm/xxx symlinks to the connectors, and if that
does matter, we'd need to recreate those manually.
Anyway, I'd also like to be able to add a virtual ttm device to the drm
sysfs hierarchy, the purpose of which would be to do the right thing
with uncached / write-combined pages at suspend. The virtual device
won't be wrapped in a drm minor so I'm wondering wether we could wrap
the struct device like so:
struct drm_sysfs_device {
enum drm_sysfs_device_type type;
struct device kdev;
}
This way the drm sysfs suspend / resume hooks can check the type of the
structure embedding the struct device and only call the driver hooks for
the relevand device types.
There is already a struct device_type mechanism for different types of
devices under a subsystem. I'm pretty sure that would be the rigth
thing to use, also for the connector devices.
The device_type methods are called in addition to the class methods.
This means we either have to a) stop the class methods from doing
anything or have them distinguish between device types like in the patch
I just posted.
So if we ditch the class suspend / resume and instead set up a struct
device_type for the minor devices to execute the suspend / resume
hooks we'd be fine. I can respin the patch to do that.
FWIW I was planning to use the struct device_type for TTM to implement
the new suspend / resume infrastructure, since when we get the legacy
suspend call it's already too late to evict VRAM buffers.
/Thomas
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm sysfs questions
Greg KH wrote:
On Wed, Aug 12, 2009 at 04:48:33PM -0700, Jesse Barnes wrote:
On Wed, 12 Aug 2009 16:24:58 -0700
Greg KH g...@kroah.com wrote:
On Wed, Aug 12, 2009 at 08:59:17AM -0700, Jesse Barnes wrote:
On Wed, 12 Aug 2009 08:21:24 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 20:29:39 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org wrote:
Hi!
I'm wondering why we are using a struct device as a sysfs
representation for connectors instead of a struct kobject?
In particular, what stops the drm_sysfs_[suspend|resume]
functions to get called for the connectors, having them cast
to a struct drm_minor and sending the cpu to the bushes?
Hm, maybe we're just getting lucky that the drm minor check
fails for everything but the DRM core device.
Yes, I think that's actually the case.
kobjects might make sense to move
to, unless we can think of other things we'd like to do with a
full device (e.g. runtime power management or some sort of
per-connector suspend/resume).
I can't really think of a case where the device owning the
connector can't handle this?
But we'd lose the /sys/drm/xxx symlinks to the connectors, and
if that does matter, we'd need to recreate those manually.
Anyway, I'd also like to be able to add a virtual ttm device
to the drm sysfs hierarchy, the purpose of which would be to
do the right thing with uncached / write-combined pages at
suspend. The virtual device won't be wrapped in a drm minor so
I'm wondering wether we could wrap the struct device like so:
struct drm_sysfs_device {
enum drm_sysfs_device_type type;
struct device kdev;
}
This way the drm sysfs suspend / resume hooks can check the
type of the structure embedding the struct device and only
call the driver hooks for the relevand device types.
Yeah, that could work, but it seems like an explicit callout
from drivers using TTM (or a callout from the core drm
suspend/resume routines conditional on a DRIVER_HAS_TTM check)
would be a bit simpler. Or did you have other TTM info you
wanted to expose sysfs as well?
TTM nowadays is a set of optional subsystems rather than a
complete set of features, so DRIVER_HAS_TTM can really mean a lot
of things.
The idea is to have a ttm subdir (representing the TTM virtual
device) and in that sysfs directory, other TTM subsystems can
register kobjects with various attributes. For example the memory
accounting subsystem with settable / readable limits and readable
status, but that will be code internal to TTM.
Don't use raw kobjects if at all possible please. Use a real struct
device, it's much better in the long run for a wide variety of
reasons, not the least being that you are dealing with virtual
devices here.
Ah ok, so the approach you suggested sounds pretty good. The only
thing that comes to mind is whether other class devices do something
similar; i.e. maybe this code belongs in the device core instead.
Greg? (See above for some background.)
I'm sorry, but I fail to see how this concerns the driver core.
Perhaps I'm just slow this afternoon... Anyone want to explain it
better?
So right now we have a DRM class device. The various DRM devices are
registered with it... and now that I think about it we should probably
just restructure things so that they each have their own suspend/resume
routines? I'm not sure how that interacts with the class device
though; will both the class device suspend/resume get called along with
each device?
Yes. They will be called first, like they should. Just like network
devices are.
Thomas's thought was to identify each sub-device uniquely so we could
do the right thing in the class device suspend/resume routines, but it
seems like that wouldn't be necessary if moved things around a bit
more...
Yeah, it sounds like the infrastructure is all there for you already :)
I don't think we can do pm per device but we can do it per struct
device_type, so anyone wanting to customize a drm sysfs device can just
implement and point to a new struct device_type before registering it,
and, as pointed out in the mail to Kristian, we should probably make the
class methods noops.
/Thomas.
thanks,
greg k-h
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Re: drm sysfs questions
On Wed, Aug 12, 2009 at 08:59:17AM -0700, Jesse Barnes wrote:
On Wed, 12 Aug 2009 08:21:24 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 20:29:39 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org wrote:
Hi!
I'm wondering why we are using a struct device as a sysfs
representation for connectors instead of a struct kobject?
In particular, what stops the drm_sysfs_[suspend|resume]
functions to get called for the connectors, having them cast to
a struct drm_minor and sending the cpu to the bushes?
Hm, maybe we're just getting lucky that the drm minor check fails
for everything but the DRM core device.
Yes, I think that's actually the case.
kobjects might make sense to move
to, unless we can think of other things we'd like to do with a
full device (e.g. runtime power management or some sort of
per-connector suspend/resume).
I can't really think of a case where the device owning the
connector can't handle this?
But we'd lose the /sys/drm/xxx symlinks to the connectors, and if
that does matter, we'd need to recreate those manually.
Anyway, I'd also like to be able to add a virtual ttm device to the
drm sysfs hierarchy, the purpose of which would be to do the right
thing with uncached / write-combined pages at suspend. The virtual
device won't be wrapped in a drm minor so I'm wondering wether we
could wrap the struct device like so:
struct drm_sysfs_device {
enum drm_sysfs_device_type type;
struct device kdev;
}
This way the drm sysfs suspend / resume hooks can check the type of
the structure embedding the struct device and only call the driver
hooks for the relevand device types.
Yeah, that could work, but it seems like an explicit callout from
drivers using TTM (or a callout from the core drm suspend/resume
routines conditional on a DRIVER_HAS_TTM check) would be a bit
simpler. Or did you have other TTM info you wanted to expose sysfs
as well?
TTM nowadays is a set of optional subsystems rather than a complete
set of features, so DRIVER_HAS_TTM can really mean a lot of things.
The idea is to have a ttm subdir (representing the TTM virtual
device) and in that sysfs directory, other TTM subsystems can
register kobjects with various attributes. For example the memory
accounting subsystem with settable / readable limits and readable
status, but that will be code internal to TTM.
Don't use raw kobjects if at all possible please. Use a real struct
device, it's much better in the long run for a wide variety of reasons,
not the least being that you are dealing with virtual devices here.
Ah ok, so the approach you suggested sounds pretty good. The only
thing that comes to mind is whether other class devices do something
similar; i.e. maybe this code belongs in the device core instead.
Greg? (See above for some background.)
I'm sorry, but I fail to see how this concerns the driver core. Perhaps
I'm just slow this afternoon... Anyone want to explain it better?
thanks,
greg k-h
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23172] Game is lagging very much with Mesa 7.5
http://bugs.freedesktop.org/show_bug.cgi?id=23172 Simonas obuol...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Simonas obuol...@gmail.com 2009-08-13 00:57:11 PST --- Thank you so much! I added my user to group video and now everything is fine! Again, Thanks awesome community :) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: fixup include files in drm_encoder_slave.h
Signed-off-by: Pekka Paalanen p...@iki.fi --- include/drm/drm_encoder_slave.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/drm/drm_encoder_slave.h b/include/drm/drm_encoder_slave.h index 821ec40..e5e5c94 100644 --- a/include/drm/drm_encoder_slave.h +++ b/include/drm/drm_encoder_slave.h @@ -27,8 +27,8 @@ #ifndef __DRM_ENCODER_SLAVE_H__ #define __DRM_ENCODER_SLAVE_H__ -#include drm/drmP.h -#include drm/drm_crtc.h +#include drmP.h +#include drm_crtc.h /** * struct drm_encoder_slave_funcs - Entry points exposed by a slave encoder driver -- 1.6.3.3 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Fix up vertical blank interrupt support.
From: Michel Dänzer daen...@vmware.com
Fixes 3D apps timing out in the WAIT_VBLANK ioctl.
AVIVO bits compile-tested only.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/r100.c | 66 +
drivers/gpu/drm/radeon/r500_reg.h | 16 -
drivers/gpu/drm/radeon/radeon.h |2 +
drivers/gpu/drm/radeon/radeon_asic.h| 23 ++--
drivers/gpu/drm/radeon/radeon_irq_kms.c | 54 --
drivers/gpu/drm/radeon/radeon_kms.c | 33 +--
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |7 +-
drivers/gpu/drm/radeon/radeon_reg.h | 11 ++-
drivers/gpu/drm/radeon/rs600.c | 82 +++
9 files changed, 217 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 4dd80e9..69c3195 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -251,6 +251,72 @@ void r100_mc_fini(struct radeon_device *rdev)
/*
+ * Interrupts
+ */
+int r100_irq_set(struct radeon_device *rdev)
+{
+ uint32_t tmp = 0;
+
+ if (rdev-irq.sw_int) {
+ tmp |= RADEON_SW_INT_ENABLE;
+ }
+ if (rdev-irq.crtc_vblank_int[0]) {
+ tmp |= RADEON_CRTC_VBLANK_MASK;
+ }
+ if (rdev-irq.crtc_vblank_int[1]) {
+ tmp |= RADEON_CRTC2_VBLANK_MASK;
+ }
+ WREG32(RADEON_GEN_INT_CNTL, tmp);
+ return 0;
+}
+
+static inline uint32_t r100_irq_ack(struct radeon_device *rdev)
+{
+ uint32_t irqs = RREG32(RADEON_GEN_INT_STATUS);
+ uint32_t irq_mask = RADEON_SW_INT_TEST | RADEON_CRTC_VBLANK_STAT |
+ RADEON_CRTC2_VBLANK_STAT;
+
+ if (irqs) {
+ WREG32(RADEON_GEN_INT_STATUS, irqs);
+ }
+ return irqs irq_mask;
+}
+
+int r100_irq_process(struct radeon_device *rdev)
+{
+ uint32_t status;
+
+ status = r100_irq_ack(rdev);
+ if (!status) {
+ return IRQ_NONE;
+ }
+ while (status) {
+ /* SW interrupt */
+ if (status RADEON_SW_INT_TEST) {
+ radeon_fence_process(rdev);
+ }
+ /* Vertical blank interrupts */
+ if (status RADEON_CRTC_VBLANK_STAT) {
+ drm_handle_vblank(rdev-ddev, 0);
+ }
+ if (status RADEON_CRTC2_VBLANK_STAT) {
+ drm_handle_vblank(rdev-ddev, 1);
+ }
+ status = r100_irq_ack(rdev);
+ }
+ return IRQ_HANDLED;
+}
+
+u32 r100_get_vblank_counter(struct radeon_device *rdev, int crtc)
+{
+ if (crtc == 0)
+ return RREG32(RADEON_CRTC_CRNT_FRAME);
+ else
+ return RREG32(RADEON_CRTC2_CRNT_FRAME);
+}
+
+
+/*
* Fence emission
*/
void r100_fence_ring_emit(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/r500_reg.h
b/drivers/gpu/drm/radeon/r500_reg.h
index 036691b..e1d5e03 100644
--- a/drivers/gpu/drm/radeon/r500_reg.h
+++ b/drivers/gpu/drm/radeon/r500_reg.h
@@ -350,6 +350,7 @@
#define AVIVO_D1CRTC_BLANK_CONTROL 0x6084
#define AVIVO_D1CRTC_INTERLACE_CONTROL 0x6088
#define AVIVO_D1CRTC_INTERLACE_STATUS 0x608c
+#define AVIVO_D1CRTC_FRAME_COUNT0x60a4
#define AVIVO_D1CRTC_STEREO_CONTROL 0x60c4
/* master controls */
@@ -438,14 +439,15 @@
# define AVIVO_DC_LB_DISP1_END_ADR_SHIFT 4
# define AVIVO_DC_LB_DISP1_END_ADR_MASK 0x7ff
-#define R500_DxMODE_INT_MASK 0x6540
-#define R500_D1MODE_INT_MASK (10)
-#define R500_D2MODE_INT_MASK (18)
-
#define AVIVO_D1MODE_DATA_FORMAT0x6528
# define AVIVO_D1MODE_INTERLEAVE_EN (1 0)
#define AVIVO_D1MODE_DESKTOP_HEIGHT 0x652C
+#define AVIVO_D1MODE_VBLANK_STATUS 0x6534
+# define AVIVO_VBLANK_ACK (1 4)
#define AVIVO_D1MODE_VLINE_START_END0x6538
+#define AVIVO_DxMODE_INT_MASK 0x6540
+# define AVIVO_D1MODE_INT_MASK(1 0)
+# define AVIVO_D2MODE_INT_MASK(1 8)
#define AVIVO_D1MODE_VIEWPORT_START 0x6580
#define AVIVO_D1MODE_VIEWPORT_SIZE 0x6584
#define AVIVO_D1MODE_EXT_OVERSCAN_LEFT_RIGHT0x6588
@@ -475,6 +477,7 @@
#define AVIVO_D2CRTC_BLANK_CONTROL 0x6884
#define AVIVO_D2CRTC_INTERLACE_CONTROL 0x6888
#define AVIVO_D2CRTC_INTERLACE_STATUS 0x688c
+#define AVIVO_D2CRTC_FRAME_COUNT0x68a4
#define AVIVO_D2CRTC_STEREO_CONTROL 0x68c4
#define AVIVO_D2GRPH_ENABLE 0x6900
@@ -497,6 +500,7 @@
#define AVIVO_D2CUR_SIZE0x6c10
#define
[Bug 22372] radeon_mipmap_tree.c:114: compute_tex_image_offset: Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=22372 --- Comment #6 from Andre Maasikas amaasi...@gmail.com 2009-08-13 02:48:16 PST --- My understanding sofar (which might be completely wrong) is that _mesa_CopyTex* clears/initializes texImage fields and radeon does CopyTex* through swrast which tries to map the textures in radeonSpanRenderStart and it goes downhill from there. No idea how to fix this though. (maybe don't try to map the texobj in this state or provide own CopyTex implementation) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13973] New: radeon: kms doesn't work on AGP x1950
http://bugzilla.kernel.org/show_bug.cgi?id=13973 Summary: radeon: kms doesn't work on AGP x1950 Product: Drivers Version: 2.5 Kernel Version: v2.6.31-rc5-246-g90bc1a6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: dan...@ffwll.ch Regression: No Created an attachment (id=22703) -- (http://bugzilla.kernel.org/attachment.cgi?id=22703) complete dmesg including failing radeon init When loading the radeon drm module with modesetting enabled, modesetting fails and leaves the console and the hw in a wedged state. When X starts, it tries user mode setting but doesn't get very far. Usually it hangs in kdm. I've tried kernel modesetting a few months ago, then it worked alright. HW: 2x Dual Core Opteron 1.8GHz, 4G ram, X1950 AGP (lspci below) SW: debian amd64 lspci -nn 00:06.0 PCI bridge [0604]: Advanced Micro Devices [AMD] AMD-8111 PCI [1022:7460] (rev 07) 00:07.0 ISA bridge [0601]: Advanced Micro Devices [AMD] AMD-8111 LPC [1022:7468] (rev 05) 00:07.1 IDE interface [0101]: Advanced Micro Devices [AMD] AMD-8111 IDE [1022:7469] (rev 03) 00:07.2 SMBus [0c05]: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 [1022:746a] (rev 02) 00:07.3 Bridge [0680]: Advanced Micro Devices [AMD] AMD-8111 ACPI [1022:746b] (rev 05) 00:07.5 Multimedia audio controller [0401]: Advanced Micro Devices [AMD] AMD-8111 AC97 Audio [1022:746d] (rev 03) 00:0a.0 PCI bridge [0604]: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge [1022:7450] (rev 12) 00:0a.1 PIC [0800]: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC [1022:7451] (rev 01) 00:0b.0 PCI bridge [0604]: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge [1022:7450] (rev 12) 00:0b.1 PIC [0800]: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC [1022:7451] (rev 01) 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] 00:19.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:19.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:19.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:19.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:00.0 USB Controller [0c03]: Advanced Micro Devices [AMD] AMD-8111 USB [1022:7464] (rev 0b) 01:00.1 USB Controller [0c03]: Advanced Micro Devices [AMD] AMD-8111 USB [1022:7464] (rev 0b) 01:0a.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43) 01:0a.1 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43) 01:0a.2 USB Controller [0c03]: NEC Corporation USB 2.0 [1033:00e0] (rev 04) 01:0b.0 Mass storage controller [0180]: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller [1095:3114] (rev 02) 01:0c.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) [104c:8023] 02:09.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet [14e4:16a7] (rev 02) 04:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] AMD-8151 System Controller [1022:7454] (rev 14) 04:01.0 PCI bridge [0604]: Advanced Micro Devices [AMD] AMD-8151 AGP Bridge [1022:7455] (rev 14) 05:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV570 [Radeon X1950 Pro] [1002:7280] (rev 9a) 05:00.1 Display controller [0380]: ATI Technologies Inc RV570 [Radeon X1950 Pro] (secondary) [1002:72a0] (rev 9a) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13973] radeon: kms doesn't work on AGP x1950
http://bugzilla.kernel.org/show_bug.cgi?id=13973 --- Comment #1 from Michel Dänzer mic...@daenzer.net 2009-08-13 10:01:31 --- Does it work with radeon.agpmode=-1? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13973] radeon: kms doesn't work on AGP x1950
http://bugzilla.kernel.org/show_bug.cgi?id=13973 --- Comment #2 from Daniel Vetter dan...@ffwll.ch 2009-08-13 10:54:05 --- --- Comment #1 from Michel Dänzer mic...@daenzer.net 2009-08-13 10:01:31 --- Does it work with radeon.agpmode=-1? Yes, this works around the problem and I get a usable console with it. -Daniel -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doing better than CS ioctl ?
On Wed, 2009-08-12 at 15:27 +0100, Keith Whitwell wrote:
Dave,
The big problem with the (second) radeon approach of state objects was
that we defined those objects statically encoded them into the kernel
interface. That meant that when new hardware functionality was needed
(or discovered) we had to rev the kernel interface, usually in a fairly
ugly way.
I think Jerome's approach could be a good improvement if the state
objects it creates are defined by software at runtime, more like little
display lists than pre-defined state atoms. The danger again is that
you run into cases where you need to expand objects the verifier will
allow userspace to create, but at least in doing so you won't be
breaking existing users of the interface.
I think the key is that there should be no pre-defined format for these
state objects, simply that they should be a sequence of legal
commands/register writes that the kernel validates once and userspace
can execute multiple times.
Keith
My idea was to have state grouped together according to what they matter
for. Like glstate of texture or object in nvidia hw. Idea is that most
of the object can be valid only if we know all of their state. For
renderbuffer we need to know its format, size, tiling, for texture we
need to know its format, size, mipmap levels and possibly others state
and so on and so forth.
If we just take arbitrary packet from userspace we might end up in
situation hard to decipher. If one validated cs program a renderbuffer
and other state like zbuffer it might be valid but now if we
combine it with another validated cs things might be completely wrong,
this another cs might just change clipping and renderbuffer size
but not update the zbuffer so we might endup rendering to zbuffer
either too small or too big (too small is what we don't want to
do ;)).
So in the end you need to enforce a set of register onto userspace.
Userspace need to submit a cs which program at least this set to be
validated, we can have different set like renderbufferset(clipping,
scissor,colorbuffer,zbuffer registers), vertex set(vbo,...), shaders
set(shaders reg) and then you can combine different set to do the
rendering. I think splitting states matter because you often render
to some buffer but with different vbo or pixel shader or vertex shader
or primitive, so it sounds better to split states.
There i think we endup pretty much to what i proposed. Thing is,
i don't think packet format is the best to communicate with the kernel
as kernel will have to parse the buffer and this is resource consuming
not to mention that tracking states that way it bit painfull.
I think state object with structure defined per asic (r3xx, r5xx, r6xx)
are better, no parsing, clear split of each value and easy access to
check that all together they do somethings allowed and then
easy and quick for the kernel to build the packet out of this.
On the backward incompatibilities side it's not harder to expand those
states :
struct radeon_state {
u32 state_id;
u64 state_struct_ptr;
};
version 1: state_id = 0x501
struct rv515_texture {
u32 width;
u32 height;
...
};
version 2: state_id = 0x502
struct rv515_texture {
u32 width;
u32 height;
...
u32 texture_pixel_sampling_center; /* well anythings new */
};
So from user pov it could still use the 0x501 and kernel
will just ignore the end of the structure and will set
default safe value for those. If userspace space submit
a 0x502 then it's assume that it knows about new state
and kernel will take them into account.
I don't think this add more works or code than adding new packet
to a parser.
Anyway the biggest problem of any of such approach is that we
need to figure out how to allocate memory to store either validated
cs or kernel built packet on behalf of the program, we don't
want to abuse kernel memory allocation. And we can't allow userspace
to modify those object after they had been validated :)
Cheers,
Jerome
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22372] radeon_mipmap_tree.c:114: compute_tex_image_offset: Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=22372 --- Comment #7 from Roland Scheidegger srol...@tungstengraphics.com 2009-08-13 04:39:23 PST --- (In reply to comment #6) My understanding sofar (which might be completely wrong) is that _mesa_CopyTex* clears/initializes texImage fields and radeon does CopyTex* through swrast which tries to map the textures in radeonSpanRenderStart and it goes downhill from there. This is quite possible. CopyTexImage is definitely broken that way - you can test this with tests/subtexrate though it needs modification (replace CopyTexSubImage with corresponding CopyTexImage and skip previous TexSubImage tests which cause miptree to be defined). No idea how to fix this though. (maybe don't try to map the texobj in this state or provide own CopyTex implementation) I think the driver needs to follow what the intel driver does, that is provide own CopyTex implementation. It could be simple and always fall back to swrast (like intel does if it can't accelerate it) though we'd really want to accelerate it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22743] nexuiz game: missing weapons and enemies models
http://bugs.freedesktop.org/show_bug.cgi?id=22743 Roland Scheidegger srol...@tungstengraphics.com changed: What|Removed |Added Status|NEW |RESOLVED Component|Drivers/DRI/r300|Mesa core Resolution||NOTOURBUG --- Comment #2 from Roland Scheidegger srol...@tungstengraphics.com 2009-08-13 05:31:21 PST --- This is a nexuiz bug and should be fixed there (if it isn't already, I didn't test latest version). Note that nexuiz doesn't actually use that index which is one too large, it's just the end value to the DrawRangeElements call which is wrong. (Though, I'm not actually really sure it's against the spec to use a end value which is larger than what the bound arrays can provide and larger than the largest index value as it's a mere hint that no larger indices will be used but doesn't indicate that the end index value will be used itself - but anyway the app certainly didn't want to use that value.) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm sysfs questions
2009/8/13 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg wrote:
2009/8/11 Thomas Hellström tho...@shipmail.org:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org wrote:
Hi!
I'm wondering why we are using a struct device as a sysfs
representation for connectors instead of a struct kobject?
In particular, what stops the drm_sysfs_[suspend|resume] functions to
get called for the connectors, having them cast to a struct drm_minor
and sending the cpu to the bushes?
Hm, maybe we're just getting lucky that the drm minor check fails for
everything but the DRM core device.
Yes, I think that's actually the case.
kobjects might make sense to move
to, unless we can think of other things we'd like to do with a full
device (e.g. runtime power management or some sort of per-connector
suspend/resume).
I can't really think of a case where the device owning the connector
can't handle this?
But we'd lose the /sys/drm/xxx symlinks to the connectors, and if that
does matter, we'd need to recreate those manually.
Anyway, I'd also like to be able to add a virtual ttm device to the drm
sysfs hierarchy, the purpose of which would be to do the right thing
with uncached / write-combined pages at suspend. The virtual device
won't be wrapped in a drm minor so I'm wondering wether we could wrap
the struct device like so:
struct drm_sysfs_device {
enum drm_sysfs_device_type type;
struct device kdev;
}
This way the drm sysfs suspend / resume hooks can check the type of the
structure embedding the struct device and only call the driver hooks for
the relevand device types.
There is already a struct device_type mechanism for different types of
devices under a subsystem. I'm pretty sure that would be the rigth
thing to use, also for the connector devices.
The device_type methods are called in addition to the class methods.
This means we either have to a) stop the class methods from doing
anything or have them distinguish between device types like in the patch
I just posted.
So if we ditch the class suspend / resume and instead set up a struct
device_type for the minor devices to execute the suspend / resume
hooks we'd be fine. I can respin the patch to do that.
Yup, I think that's a great approach.
cheers,
Kristian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch 39/74] x86: Fix CPA memtype reserving in the set_pages_array*() cases
2.6.30-stable review patch. If anyone has any objections, please let us know.
--
From: Thomas Hellstrom thellst...@vmware.com
commit 8523acfe40efc1a8d3da8f473ca67cb195b06f0c upstream.
The code was incorrectly reserving memtypes using the page
virtual address instead of the physical address. Furthermore,
the code was not ignoring highmem pages as it ought to.
( upstream does not pass in highmem pages yet - but upcoming
graphics code will do it and there's no reason to not handle
this properly in the CPA APIs.)
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13884
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Acked-by: Suresh Siddha suresh.b.sid...@intel.com
Cc: dri-devel@lists.sourceforge.net
Cc: venkatesh.pallip...@intel.com
LKML-Reference: 1249284345-7654-1-git-send-email-thellst...@vmware.com
Signed-off-by: Ingo Molnar mi...@elte.hu
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
arch/x86/mm/pageattr.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -590,9 +590,12 @@ static int __change_page_attr(struct cpa
unsigned int level;
pte_t *kpte, old_pte;
- if (cpa-flags CPA_PAGES_ARRAY)
- address = (unsigned long)page_address(cpa-pages[cpa-curpage]);
- else if (cpa-flags CPA_ARRAY)
+ if (cpa-flags CPA_PAGES_ARRAY) {
+ struct page *page = cpa-pages[cpa-curpage];
+ if (unlikely(PageHighMem(page)))
+ return 0;
+ address = (unsigned long)page_address(page);
+ } else if (cpa-flags CPA_ARRAY)
address = cpa-vaddr[cpa-curpage];
else
address = *cpa-vaddr;
@@ -695,9 +698,12 @@ static int cpa_process_alias(struct cpa_
* No need to redo, when the primary call touched the direct
* mapping already:
*/
- if (cpa-flags CPA_PAGES_ARRAY)
- vaddr = (unsigned long)page_address(cpa-pages[cpa-curpage]);
- else if (cpa-flags CPA_ARRAY)
+ if (cpa-flags CPA_PAGES_ARRAY) {
+ struct page *page = cpa-pages[cpa-curpage];
+ if (unlikely(PageHighMem(page)))
+ return 0;
+ vaddr = (unsigned long)page_address(page);
+ } else if (cpa-flags CPA_ARRAY)
vaddr = cpa-vaddr[cpa-curpage];
else
vaddr = *cpa-vaddr;
@@ -1118,7 +1124,9 @@ int set_pages_array_uc(struct page **pag
int free_idx;
for (i = 0; i addrinarray; i++) {
- start = (unsigned long)page_address(pages[i]);
+ if (PageHighMem(pages[i]))
+ continue;
+ start = page_to_pfn(pages[i]) PAGE_SHIFT;
end = start + PAGE_SIZE;
if (reserve_memtype(start, end, _PAGE_CACHE_UC_MINUS, NULL))
goto err_out;
@@ -1131,7 +1139,9 @@ int set_pages_array_uc(struct page **pag
err_out:
free_idx = i;
for (i = 0; i free_idx; i++) {
- start = (unsigned long)page_address(pages[i]);
+ if (PageHighMem(pages[i]))
+ continue;
+ start = page_to_pfn(pages[i]) PAGE_SHIFT;
end = start + PAGE_SIZE;
free_memtype(start, end);
}
@@ -1160,7 +1170,9 @@ int set_pages_array_wb(struct page **pag
return retval;
for (i = 0; i addrinarray; i++) {
- start = (unsigned long)page_address(pages[i]);
+ if (PageHighMem(pages[i]))
+ continue;
+ start = page_to_pfn(pages[i]) PAGE_SHIFT;
end = start + PAGE_SIZE;
free_memtype(start, end);
}
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
