Re: radeon kms on ppc status
On Mon, 2010-08-09 at 16:16 +1000, Benjamin Herrenschmidt wrote: I'm currently testing on a rv350 based aluminium powerbooks. Same here. :) - AGP: locks up before the console shows anything useful, that's going to be fun to debug without a serial port ... I'll see what I can with netconsole or some firewire hack. Works fine with PCI GART. AGP 1x works mostly fine for me. Not sure what the problem is with higher speeds (4x used to work fine with UMS) but I guess most likely some kind of coherency issue which only matters now that we're dynamically changing GTT bindings. The reason you don't get anything useful with higher AGP speeds is that the attempt to reset the locked-up GPU kills the machine. I tried tracking this down with netconsole but the only possibly relevant info I've got out of that yet is that there seem to be some machine checks occurring. - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. I only tried this once but AFAIR it was the same for me. - The other fancy stuff... well, we could make up profiles on powerbooks I suppose, at least dynclk can be enable always and I'm sure we can make up default profiles with something like half clock speed, what do you reckon ? Might be nice, though IME the CPU seems to suck more power anyway. :) IMO the highest priority missing feature is backlight control, followed by suspend/resume. Note that there's also still outstanding KMS related endianness issues in the Mesa tree, in particular concerning r300g but also the classic driver related to the OpenGL blit functionality. I've been meaning to clean up and push my hacks for those but had little time recently. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
On Tue, 2010-08-10 at 14:56 +0200, Michel Dänzer wrote: On Mon, 2010-08-09 at 16:16 +1000, Benjamin Herrenschmidt wrote: I'm currently testing on a rv350 based aluminium powerbooks. Same here. :) Heh. Well, I also have the G5 with rv350, and that has a serial port :-) - AGP: locks up before the console shows anything useful, that's going to be fun to debug without a serial port ... I'll see what I can with netconsole or some firewire hack. Works fine with PCI GART. AGP 1x works mostly fine for me. Not sure what the problem is with higher speeds (4x used to work fine with UMS) but I guess most likely some kind of coherency issue which only matters now that we're dynamically changing GTT bindings. Ok. Well, we -know- we have a problem with AGP anyways bcs of that dual cachable/non-cachable mapping issue. I'll see if I can find ways to work around that. If not, I don't really mind sticking to x1, it's old machines and it's better than nothing. The reason you don't get anything useful with higher AGP speeds is that the attempt to reset the locked-up GPU kills the machine. I tried tracking this down with netconsole but the only possibly relevant info I've got out of that yet is that there seem to be some machine checks occurring. Right, makes sense if the card doesn't answer to an MMIO access. I'll see what I can do. - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. I only tried this once but AFAIR it was the same for me. I found some stuff there and fixed some on the G5. It now works there, I haven't tried again on the powerbook yet. One is the patch I send to do an early transition like nouveau does. The other one is you need to make sure CONFIG_VT_HW_CONSOLE_BINDING is set. Without that, unregister_framebuffer() of offb fails bcs fbcon refuses to unbind the last console. So you end up with fb1 for the drm, while fb0 remains on offb and everything breaks. We might want to make this a hard dependency. - The other fancy stuff... well, we could make up profiles on powerbooks I suppose, at least dynclk can be enable always and I'm sure we can make up default profiles with something like half clock speed, what do you reckon ? Might be nice, though IME the CPU seems to suck more power anyway. :) Right. IMO the highest priority missing feature is backlight control, followed by suspend/resume. Agreed. Note that there's also still outstanding KMS related endianness issues in the Mesa tree, in particular concerning r300g but also the classic driver related to the OpenGL blit functionality. I've been meaning to clean up and push my hacks for those but had little time recently. Ok. I'll leave you to those because I really know near to nothing about GL and Mesa ... from my quick tests, things seem to work allright with compiz on the G5 and the powerbook tho with whatever Mesa's in lucid. Also, the few tests I did on the quad G5 with nvidia 6600 nouveau were interesting as well (gallium in that case). nouveau itself works well, but the mesa part doesn't (renders black). The interesting thing tho was that all the SW rendering path seemed to work well, which is a nice change from not that long ago where all the fallbacks were endian broken. I suspect you may have done some fixing there :-) Cheers, Ben. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon kms on ppc status
Just a quick status in case others are interested and want to help as I have -very- little time. I'm currently testing on a rv350 based aluminium powerbooks. The basic stuff works provided you stay away from AGP. Here's things in no special order I noticed: - AGP: locks up before the console shows anything useful, that's going to be fun to debug without a serial port ... I'll see what I can with netconsole or some firewire hack. Works fine with PCI GART. - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. Note that it seems broken with nouveau on the G5 as well, I suspect we are passing a crap mode when picking up from offb at boot. - Power Management. - Sleep/wakeup needs to be ported over from radeonfb (will also be useful for some x86 models). - The other fancy stuff... well, we could make up profiles on powerbooks I suppose, at least dynclk can be enable always and I'm sure we can make up default profiles with something like half clock speed, what do you reckon ? Cheers, Ben. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
2010/8/9 Benjamin Herrenschmidt b...@kernel.crashing.org: Just a quick status in case others are interested and want to help as I have -very- little time. Unfortunately, I don't have much spare time to dedicate to this either and I don't have any ppc machines. I'm currently testing on a rv350 based aluminium powerbooks. The basic stuff works provided you stay away from AGP. Here's things in no special order I noticed: - AGP: locks up before the console shows anything useful, that's going to be fun to debug without a serial port ... I'll see what I can with netconsole or some firewire hack. Works fine with PCI GART. I think Michel had it working with 1x AGP. - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. Note that it seems broken with nouveau on the G5 as well, I suspect we are passing a crap mode when picking up from offb at boot. - Power Management. - Sleep/wakeup needs to be ported over from radeonfb (will also be useful for some x86 models). It would be nice to get this ported over. - The other fancy stuff... well, we could make up profiles on powerbooks I suppose, at least dynclk can be enable always and I'm sure we can make up default profiles with something like half clock speed, what do you reckon ? The dynclks in the drm should work on the ppc. As for the power profiles, something like a half clock should work. Probably also useful to come up with some way to add backlight control to the macs without conflicting with the acpi backlight stuff on x86. Alex -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
2010/8/9 Benjamin Herrenschmidt b...@kernel.crashing.org: Just a quick status in case others are interested and want to help as I have -very- little time. I'm currently testing on a rv350 based aluminium powerbooks. The basic stuff works provided you stay away from AGP. Here's things in no special order I noticed: - AGP: locks up before the console shows anything useful, that's going to be fun to debug without a serial port ... I'll see what I can with netconsole or some firewire hack. Works fine with PCI GART. - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. Note that it seems broken with nouveau on the G5 as well, I suspect we are passing a crap mode when picking up from offb at boot. wierd offb-nouveau worked on my G5, handoff doesn't do anything technically other than just remove offb from the system, and start the driver, so it should be like setting an initial mode. Unless the newer early handover messed it up. - Power Management. - Sleep/wakeup needs to be ported over from radeonfb (will also be useful for some x86 models). I've started to port this on the M7 in a thinkpad on my desk, in theory it should save battery life as it appears currently the GPU doesn't go into D3 properly, however I haven't figured out exactly which bits are required, or proven its saving battery (the battery is a little old so I can't be sure). Dave. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
On Mon, 2010-08-09 at 03:18 -0400, Alex Deucher wrote: 2010/8/9 Benjamin Herrenschmidt b...@kernel.crashing.org: Just a quick status in case others are interested and want to help as I have -very- little time. Unfortunately, I don't have much spare time to dedicate to this either and I don't have any ppc machines. I guessed :-) We'll see what we manage. - AGP: locks up before the console shows anything useful, that's going to be fun to debug without a serial port ... I'll see what I can with netconsole or some firewire hack. Works fine with PCI GART. I think Michel had it working with 1x AGP. Interesting. Michel, any idea what the problems might be ? - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. Note that it seems broken with nouveau on the G5 as well, I suspect we are passing a crap mode when picking up from offb at boot. - Power Management. - Sleep/wakeup needs to be ported over from radeonfb (will also be useful for some x86 models). It would be nice to get this ported over. Most definitely. I'm still getting my head around the KMS driver structure. - The other fancy stuff... well, we could make up profiles on powerbooks I suppose, at least dynclk can be enable always and I'm sure we can make up default profiles with something like half clock speed, what do you reckon ? The dynclks in the drm should work on the ppc. As for the power profiles, something like a half clock should work. Ok. Here too, trying to sort out what the driver is doing for now, and we'll move from there. Probably also useful to come up with some way to add backlight control to the macs without conflicting with the acpi backlight stuff on x86. Yup, forgot about that one. Shouldn't be -too- hard. Cheers, Ben. Alex -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
- transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. Note that it seems broken with nouveau on the G5 as well, I suspect we are passing a crap mode when picking up from offb at boot. wierd offb-nouveau worked on my G5, handoff doesn't do anything technically other than just remove offb from the system, and start the driver, so it should be like setting an initial mode. Unless the newer early handover messed it up. Yeah, not sure what's up, I suspect the driver get passed a bogus mode in the initial set_par() when doing the handover. I'll see what I can find out once I dig out my dual G5 which has a serial port :-) - Power Management. - Sleep/wakeup needs to be ported over from radeonfb (will also be useful for some x86 models). I've started to port this on the M7 in a thinkpad on my desk, in theory it should save battery life as it appears currently the GPU doesn't go into D3 properly, however I haven't figured out exactly which bits are required, or proven its saving battery (the battery is a little old so I can't be sure). Ok. So there's basically two different things in that code. Merely D2 sleep and re-POST (aka D3 cold). The former is supported on M6, M7 and M9 (at least some of these, the code might need tweaks to work on non-powerbooks). In this case, we are dealing with cases where the chip isn't powered down by the motherboard or firmware. I don't actually know for sure -what- happens to it on the relevant powerbooks actually, I suspect the clocks might go off, and/or the VRAM is off. IE. If I don't run that code, I don't come back. The code was essentially contributed by ATI btw. Then there's code for M10/M11 which re-POSTs the chip. It mostly relies on saving as much registers as can be and restoring things in the right order, along with the right magic to restart PLLs, MC, DLLs, ... This code was written after analyzing the MacOS driver IO traces. Some parts however cannot be saved/restored (memory init sequence), so in that case, I have a default sequence, and I have code to retreive a different one from the OF device-tree when available. For that code to work more generically/better on x86's, we might want to add code to extract that from the BIOS tables. Now, I need to figure out how to make all this fit in our driver architecture. Dave, can I see your patches ? That might give me some good hints to get started. Hopefully, most of that can be kept safely in the r100 files and we can avoid clobbering too much of the core drivers. Cheers, Ben. Dave. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
On Mon, Aug 9, 2010 at 8:24 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. Note that it seems broken with nouveau on the G5 as well, I suspect we are passing a crap mode when picking up from offb at boot. wierd offb-nouveau worked on my G5, handoff doesn't do anything technically other than just remove offb from the system, and start the driver, so it should be like setting an initial mode. Unless the newer early handover messed it up. Yeah, not sure what's up, I suspect the driver get passed a bogus mode in the initial set_par() when doing the handover. I'll see what I can find out once I dig out my dual G5 which has a serial port :-) - Power Management. - Sleep/wakeup needs to be ported over from radeonfb (will also be useful for some x86 models). I've started to port this on the M7 in a thinkpad on my desk, in theory it should save battery life as it appears currently the GPU doesn't go into D3 properly, however I haven't figured out exactly which bits are required, or proven its saving battery (the battery is a little old so I can't be sure). Ok. So there's basically two different things in that code. Merely D2 sleep and re-POST (aka D3 cold). The former is supported on M6, M7 and M9 (at least some of these, the code might need tweaks to work on non-powerbooks). In this case, we are dealing with cases where the chip isn't powered down by the motherboard or firmware. I don't actually know for sure -what- happens to it on the relevant powerbooks actually, I suspect the clocks might go off, and/or the VRAM is off. IE. If I don't run that code, I don't come back. The code was essentially contributed by ATI btw. Then there's code for M10/M11 which re-POSTs the chip. It mostly relies on saving as much registers as can be and restoring things in the right order, along with the right magic to restart PLLs, MC, DLLs, ... This code was written after analyzing the MacOS driver IO traces. Some parts however cannot be saved/restored (memory init sequence), so in that case, I have a default sequence, and I have code to retreive a different one from the OF device-tree when available. For that code to work more generically/better on x86's, we might want to add code to extract that from the BIOS tables. The drm can already post the chip using the bios tables on x86, so we'd only need that for macs. Now, I need to figure out how to make all this fit in our driver architecture. Dave, can I see your patches ? That might give me some good hints to get started. Hopefully, most of that can be kept safely in the r100 files and we can avoid clobbering too much of the core drivers. For chip init, you'd want to hook asic init stuff into radeon_combios_asic_init() in radeon_combios.c. That function uses the bios tables to init the chip. For the D2 stuff, you'd want to hook that into the r100_suspend/resume functions in r100.c and r300_suspend/resume in r300.c. Alex Cheers, Ben. Dave. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/i915: blacklist lid status: Sony VGN-BX196VP
BugLink: http://launchpad.net/bug/515246
Sony VGN-BX196VP reports the lid status as closed when it is open. This
leads to a no connectors reported error at startup. Blacklisting
it to always return a connected status for the default lvds connector.
Signed-off-by: Surbhi Palande surbhi.pala...@canonical.com
---
drivers/gpu/drm/i915/intel_lvds.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index c2e8a45..afd0ee7 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -643,6 +643,13 @@ static const struct dmi_system_id bad_lid_status[] = {
DMI_MATCH(DMI_BOARD_NAME, M5x0N),
},
},
+ {
+ .ident = Sony VGN-BX196VP,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_BOARD_NAME, VGN-BX196VP),
+ },
+ },
{ }
};
--
1.6.3.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/2] blacklist lid status: Sony VGN-BX196VP and Elite Co.
The following two patches are quirks that blacklist bios which report incorrect lid status. These are bioses for machines with a 900 GM. The first one is tested by Ubuntu users and the second one isn't. Further testing will be appreciated. Surbhi Palande (2): drm/i915: blacklist lid status: Sony VGN-BX196VP drm/i915: blacklist lid status: Elite Co. G335 drivers/gpu/drm/i915/intel_lvds.c | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/i915: blacklist lid status: Elite Co. G335
BugLink: http://launchpad.net/bug/515246
Elite Computers G335 reports the lid status as closed when it is open. This
leads to a no connectors reported error at startup. Blacklisting
it to always return a connected status for the default lvds connector.
Signed-off-by: Surbhi Palande surbhi.pala...@canonical.com
---
drivers/gpu/drm/i915/intel_lvds.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index afd0ee7..b75a941 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -650,6 +650,13 @@ static const struct dmi_system_id bad_lid_status[] = {
DMI_MATCH(DMI_BOARD_NAME, VGN-BX196VP),
},
},
+ {
+ .ident = Elitegroup ECS G335,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Elitegroup Co.),
+ DMI_MATCH(DMI_BOARD_NAME, ECS G335),
+ },
+ },
{ }
};
--
1.6.3.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch 3/3] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m
From: Surbhi Palande surbhi.pala...@canonical.com
Sony VGN-BX196VP and Dell Inspiron 700m report lid status as closed when
it is open. This leads to a no connectors reported error at startup.
Blacklisting them, to always return a connected status for the default
lvds connector.
Addresses https://bugs.launchpad.net/bugs/515246
Signed-off-by: Surbhi Palande surbhi.pala...@canonical.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/gpu/drm/i915/intel_lvds.c | 14 ++
1 file changed, 14 insertions(+)
diff -puN
drivers/gpu/drm/i915/intel_lvds.c~drm-i915-blacklist-lid-status-sony-vgn-bx196vp-dell-inspiron-700m
drivers/gpu/drm/i915/intel_lvds.c
---
a/drivers/gpu/drm/i915/intel_lvds.c~drm-i915-blacklist-lid-status-sony-vgn-bx196vp-dell-inspiron-700m
+++ a/drivers/gpu/drm/i915/intel_lvds.c
@@ -651,6 +651,20 @@ static const struct dmi_system_id bad_li
DMI_MATCH(DMI_BOARD_NAME, M5x0N),
},
},
+ {
+ .ident = Sony VGN-BX196VP,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_BOARD_NAME, VGN-BX196VP),
+ },
+ },
+ {
+ .ident = Dell Inspiron 700m,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc),
+ DMI_MATCH(DMI_BOARD_NAME, Inspiron 700m),
+ },
+ },
{ }
};
_
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 3/3] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m
On Thu, 11 Mar 2010 14:01:40 -0800, a...@linux-foundation.org wrote:
+ {
+ .ident = Dell Inspiron 700m,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc),
+ DMI_MATCH(DMI_BOARD_NAME, Inspiron 700m),
+ },
+ },
The Inspiron 700m has a 855GME part, so is caught by (which is heading
upstream, if not already been pulled into Linus' tree):
commit 7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri Feb 12 09:30:00 2010 -0800
drm/i915: give up on 8xx lid status
These old machines more often than not lie about their lid state. So
don't use it to detect LVDS presence, but leave the event handler to
deal with lid open/close, when we might need to reset the mode.
Fixes kernel bug #15248
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Cc: sta...@kernel.org
Signed-off-by: Eric Anholt e...@anholt.net
The Sony has a GMA 900, so does indeed need the quirk.
-ickle
--
Chris Wilson, Intel Open Source Technology Centre
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m
Hi Eric, On Wed, 2010-03-03 at 15:34 -0800, Eric Anholt wrote: On Tue, 2 Mar 2010 22:59:52 +0200, Surbhi Palande surbhi.pala...@canonical.com wrote: BugLink: https://bugs.launchpad.net/bugs/515246 Sony VGN-BX196VP and Dell Inspiron 700m report lid status as closed when it is open. This leads to a no connectors reported error at startup. Blacklisting them, to always return a connected status for the default lvds connector. Signed-off-by: Surbhi Palande surbhi.pala...@canonical.com As far as I know, this should already be covered by: commit 7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Fri Feb 12 09:30:00 2010 -0800 drm/i915: give up on 8xx lid status Yes I agree. Thanks for the comment. However, the drm/i915: give up on 8xx lid status will work for the Dell Inspiron 700m. But, the Sony VGN-BX196VP will still need to be blacklisted as it is a 915GM device. If you agree with this, I will rewrite the patch and send you another version. Thanks! Warm Regards, Surbhi. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m
On Tue, 2 Mar 2010 22:59:52 +0200, Surbhi Palande surbhi.pala...@canonical.com wrote: BugLink: https://bugs.launchpad.net/bugs/515246 Sony VGN-BX196VP and Dell Inspiron 700m report lid status as closed when it is open. This leads to a no connectors reported error at startup. Blacklisting them, to always return a connected status for the default lvds connector. Signed-off-by: Surbhi Palande surbhi.pala...@canonical.com As far as I know, this should already be covered by: commit 7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Fri Feb 12 09:30:00 2010 -0800 drm/i915: give up on 8xx lid status pgpNe85gsm2Yr.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m
BugLink: https://bugs.launchpad.net/bugs/515246
Sony VGN-BX196VP and Dell Inspiron 700m report lid status as closed
when it is open. This leads to a no connectors reported error at startup.
Blacklisting them, to always return a connected status for the default
lvds connector.
Signed-off-by: Surbhi Palande surbhi.pala...@canonical.com
---
Due to lack of hardware, I have not tested this patch on my own. Further
testing shall be helpful.
drivers/gpu/drm/i915/intel_lvds.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index c2e8a45..b94a5e5 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -643,6 +643,20 @@ static const struct dmi_system_id bad_lid_status[] = {
DMI_MATCH(DMI_BOARD_NAME, M5x0N),
},
},
+ {
+ .ident = Sony VGN-BX196VP,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_BOARD_NAME, VGN-BX196VP),
+ },
+ },
+ {
+ .ident = Dell Inspiron 700m,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc),
+ DMI_MATCH(DMI_BOARD_NAME, Inspiron 700m),
+ },
+ },
{ }
};
--
1.6.3.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm: switch all GEM/KMS ioctls to unlocked ioctl status.
On Thu, 4 Feb 2010 06:29:05 +1000, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com These ioctls are all protected by their own locking mechanisms so should be fine to not bother locking around. Seems good to me. At some point we should just push it down and not have the flag. pgpLytlFSpEfP.pgp Description: PGP signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm: switch all GEM/KMS ioctls to unlocked ioctl status.
From: Dave Airlie airl...@redhat.com
These ioctls are all protected by their own locking mechanisms so
should be fine to not bother locking around.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_drv.c | 44 ++--
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 766c468..f3c58e2 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -125,28 +125,28 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_UPDATE_DRAW, drm_update_drawable_info,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, 0),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl, DRM_AUTH),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, DRM_AUTH),
-
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR, drm_mode_cursor_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETGAMMA, drm_mode_gamma_get_ioctl,
DRM_MASTER),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETGAMMA, drm_mode_gamma_set_ioctl,
DRM_MASTER),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETENCODER, drm_mode_getencoder,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATTACHMODE, drm_mode_attachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_DETACHMODE, drm_mode_detachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPERTY, drm_mode_getproperty_ioctl,
DRM_MASTER | DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPROPERTY,
drm_mode_connector_property_set_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_PAGE_FLIP, drm_mode_page_flip_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_DIRTYFB, drm_mode_dirtyfb_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW)
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR, drm_mode_cursor_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETGAMMA, drm_mode_gamma_get_ioctl,
DRM_MASTER|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETGAMMA, drm_mode_gamma_set_ioctl,
DRM_MASTER|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETENCODER, drm_mode_getencoder,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATTACHMODE, drm_mode_attachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_DETACHMODE, drm_mode_detachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPERTY, drm_mode_getproperty_ioctl,
DRM_MASTER | DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPROPERTY,
drm_mode_connector_property_set_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_PAGE_FLIP, drm_mode_page_flip_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_DIRTYFB, drm_mode_dirtyfb_ioctl,
Re: [Intel-gfx] [PATCH 2/2] drm/i915: enable 36bit physical address for hardware status page
On 2010.01.15 14:51:41 -0800, Eric Anholt wrote: On Tue, 5 Jan 2010 11:25:06 +0800, Zhenyu Wang zhen...@linux.intel.com wrote: This enables possible 36bit address mask on 965G that use physical address for hw status page. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com Applied to for-linus. Thanks! My understanding is that with the current 2 patches applied, the other swiotlb stuff in intel-agp is not required. Is that right? Yes. We've already tried to make dma mapping stuff in intel-agp to work with any pci mapping implement, so does swiotlb now although we just pass through it. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] drm/i915: enable 36bit physical address for hardware status page
On Tue, 5 Jan 2010 11:25:06 +0800, Zhenyu Wang zhen...@linux.intel.com wrote: This enables possible 36bit address mask on 965G that use physical address for hw status page. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com Applied to for-linus. Thanks! My understanding is that with the current 2 patches applied, the other swiotlb stuff in intel-agp is not required. Is that right? pgpZ3RjzqNgUb.pgp Description: PGP signature -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] drm/i915: enable 36bit physical address for hardware status page
On 2010.01.05 13:37:00 +0800, ykzhao wrote: Do we need to add the explicit DMA mask for using 32bit DMA mask? No, 32bit mask is the default. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] drm/i915: enable 36bit physical address for hardware status page
On Tue, 2010-01-05 at 11:25 +0800, Zhenyu Wang wrote:
This enables possible 36bit address mask on 965G that use physical
address for hw status page.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/char/agp/intel-agp.c|6 +-
drivers/gpu/drm/i915/i915_dma.c |4
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 30c36ac..3999a5f 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -2460,10 +2460,14 @@ static int __devinit agp_intel_probe(struct pci_dev
*pdev,
bridge-mode);
}
- if (bridge-driver-mask_memory == intel_i965_mask_memory)
+ if (bridge-driver-mask_memory == intel_i965_mask_memory) {
if (pci_set_dma_mask(intel_private.pcidev, DMA_BIT_MASK(36)))
dev_err(intel_private.pcidev-dev,
set gfx device dma mask 36bit failed!\n);
+ else
+ pci_set_consistent_dma_mask(intel_private.pcidev,
+ DMA_BIT_MASK(36));
+ }
It seems that both pci_set_dma_mask/set_consistent_dma_mask will be
called when the DMA mask is set correctly.
Can we use the following format so that it is easy to understand?
if (!pci_set_dma_mask() !pci_set_consistent_dma_mask()) {
success;
} else
failure;
Do we need to add the explicit DMA mask for using 32bit DMA mask?
pci_set_drvdata(pdev, bridge);
return agp_add_bridge(bridge);
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 02607ed..750f6c8 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -134,6 +134,10 @@ static int i915_init_phys_hws(struct drm_device *dev)
memset(dev_priv-hw_status_page, 0, PAGE_SIZE);
+ if (IS_I965G(dev))
+ dev_priv-dma_status_page |= (dev_priv-dma_status_page 28)
+ 0xf0;
+
I915_WRITE(HWS_PGA, dev_priv-dma_status_page);
DRM_DEBUG_DRIVER(Enabled hardware status page\n);
return 0;
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Radeon KMS status (Re: [git pull] drm radeon kms.)
Hi Dave, I was wondering about the current state of Radeon KMS, how far are we from having it removed from staging? -- 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: Radeon KMS status (Re: [git pull] drm radeon kms.)
Hi Dave, I was wondering about the current state of Radeon KMS, how far are we from having it removed from staging? I'm sort of thinking the next merge window of moving the enable option into the kernel proper. We still have a metric shitload of work to get to feature parity with current userspace drivers and we've done no optimisation work on the rendering portion of the stack so I'm not sure freezing the API isn't a bit premature, however maybe the API we have is good enough to support and we can add new ioctls to make it go faster if we require. Jerome has proposed some API changes but we really haven't had time to validate them in any useful way. Dave. -- 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: Radeon KMS status (Re: [git pull] drm radeon kms.)
I'm sort of thinking the next merge window of moving the enable option into the kernel proper. We still have a metric shitload of work to get to feature parity with current userspace drivers and we've done no optimisation work on the rendering portion of the stack so I'm not sure freezing the API isn't a bit premature, however maybe the API we have is good enough to support and we can add new ioctls to make it go faster if we require. Jerome has proposed some API changes but we really haven't had time to validate them in any useful way. I by no means intend to rush things along, so if you think you need more time, please take it ;-) Just wanted to know where we stand... I'll try the Radeon KMS thing again once I get through this mountain of email that accumulated over the vacation and let you know how the current bits work. Last time I tried KMS swapped the two DVI outputs wrt. the !KMS setup, which is rather annoying during the transition period, but nothing I can't live with once the stuff is stable enough to use all day. The easiest way to test it jsut grab an F12 LiveCD http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ Its pretty much got what I've just asked Linus to pull, and won't ruin your already installed system, handy for testing s/r if ppl use it. Dave. -- 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: Radeon KMS status (Re: [git pull] drm radeon kms.)
On Wed, 2009-11-11 at 09:14 +, Dave Airlie wrote: Hi Dave, I was wondering about the current state of Radeon KMS, how far are we from having it removed from staging? I'm sort of thinking the next merge window of moving the enable option into the kernel proper. We still have a metric shitload of work to get to feature parity with current userspace drivers and we've done no optimisation work on the rendering portion of the stack so I'm not sure freezing the API isn't a bit premature, however maybe the API we have is good enough to support and we can add new ioctls to make it go faster if we require. Jerome has proposed some API changes but we really haven't had time to validate them in any useful way. I by no means intend to rush things along, so if you think you need more time, please take it ;-) Just wanted to know where we stand... I'll try the Radeon KMS thing again once I get through this mountain of email that accumulated over the vacation and let you know how the current bits work. Last time I tried KMS swapped the two DVI outputs wrt. the !KMS setup, which is rather annoying during the transition period, but nothing I can't live with once the stuff is stable enough to use all day. -- 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: Changing cache status while validating object
On Wed, 2009-07-29 at 21:53 +0200, Thomas Hellström wrote: Jerome Glisse skrev: Hi Thomas, I think ttm is doing somethings wrong when we validate a bo for the same mem type but with different cache flags. Here is my understanding : (Use case i am refering too is object validate with current state GTT | CACHED validate to GTT | WC) if (!ttm_bo_mem_compat(bo-proposed_placement, bo-mem) Is evaluate as true because cache flags are differents, For instance is it goes from UNCACHED to WC or CACHED. So ttm_bo_move_buffer get call, which call ttm_bo_handle_move_memin there caching change will only happen if there is no ttm allocated which might not be the case if for instance we are dealing with GTT memory (so i think cache transitioning of the object is wrong and we should move ttm_tt_set_placement_caching outside the if in ttm_bo_handle_move_mem). In this particular case, ttm_bo_handle_move_mem will first call ttm_bo_unmap_virtual(), then go ahead and call ttm_bo_move_ttm(). This routine will unbind from GTT, change caching and the rebind to GTT. ttm_bo_handle_move_mem will end up calling driver callback move routine No, it will use ttm_bo_move_ttm(). which will call in radeon case the ttm_bo_move_accel_cleanup and which will create a ghost object holding the ttm memory in order to delete it at latter point (which is wrong as this memory is still needed). So shouldn't the ttm_bo_move_buffer catch this and not call device move callback but simply transition cache setup of the object ? Or do i misunderstand somethings ? It should call ttm_bo_move_ttm() and hopefully it does. However, it is a bit wasteful of GTT space since I think it actually allocates a new GTT slot before freeing the old one. Ideally I think it should reuse the old slot. There's some optimization to be done there. So why does it bother unbinding from GTT in the first place? This is because translation tables that support both snooped and unsnooped bindings usually need to rewrite the page tables to reflect this change. Cheers, Jerome /Thomas I need to do more debugging but i am seeing again massive pte corruption and i thought i spotted the right path. 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
Changing cache status while validating object
Hi Thomas, I think ttm is doing somethings wrong when we validate a bo for the same mem type but with different cache flags. Here is my understanding : (Use case i am refering too is object validate with current state GTT | CACHED validate to GTT | WC) if (!ttm_bo_mem_compat(bo-proposed_placement, bo-mem) Is evaluate as true because cache flags are differents, For instance is it goes from UNCACHED to WC or CACHED. So ttm_bo_move_buffer get call, which call ttm_bo_handle_move_mem in there caching change will only happen if there is no ttm allocated which might not be the case if for instance we are dealing with GTT memory (so i think cache transitioning of the object is wrong and we should move ttm_tt_set_placement_caching outside the if in ttm_bo_handle_move_mem). ttm_bo_handle_move_mem will end up calling driver callback move routine which will call in radeon case the ttm_bo_move_accel_cleanup and which will create a ghost object holding the ttm memory in order to delete it at latter point (which is wrong as this memory is still needed). So shouldn't the ttm_bo_move_buffer catch this and not call device move callback but simply transition cache setup of the object ? Or do i misunderstand somethings ? 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
Re: Changing cache status while validating object
Jerome Glisse skrev: Hi Thomas, I think ttm is doing somethings wrong when we validate a bo for the same mem type but with different cache flags. Here is my understanding : (Use case i am refering too is object validate with current state GTT | CACHED validate to GTT | WC) if (!ttm_bo_mem_compat(bo-proposed_placement, bo-mem) Is evaluate as true because cache flags are differents, For instance is it goes from UNCACHED to WC or CACHED. So ttm_bo_move_buffer get call, which call ttm_bo_handle_move_memin there caching change will only happen if there is no ttm allocated which might not be the case if for instance we are dealing with GTT memory (so i think cache transitioning of the object is wrong and we should move ttm_tt_set_placement_caching outside the if in ttm_bo_handle_move_mem). In this particular case, ttm_bo_handle_move_mem will first call ttm_bo_unmap_virtual(), then go ahead and call ttm_bo_move_ttm(). This routine will unbind from GTT, change caching and the rebind to GTT. ttm_bo_handle_move_mem will end up calling driver callback move routine No, it will use ttm_bo_move_ttm(). which will call in radeon case the ttm_bo_move_accel_cleanup and which will create a ghost object holding the ttm memory in order to delete it at latter point (which is wrong as this memory is still needed). So shouldn't the ttm_bo_move_buffer catch this and not call device move callback but simply transition cache setup of the object ? Or do i misunderstand somethings ? It should call ttm_bo_move_ttm() and hopefully it does. However, it is a bit wasteful of GTT space since I think it actually allocates a new GTT slot before freeing the old one. Ideally I think it should reuse the old slot. There's some optimization to be done there. So why does it bother unbinding from GTT in the first place? This is because translation tables that support both snooped and unsnooped bindings usually need to rewrite the page tables to reflect this change. Cheers, Jerome /Thomas /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
[PATCH] drm: get connector status fix
In drm_mode_getconnector we send the connector status back to userspace. However, we only return the last detected status, rather than performing status detection again, which can lead to trouble if the configuration changes after module load and initial probing is done. Since drm_mode_getconnector currently has full probe semantics, make it return a current status at all times so that config changes are properly picked up. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 94a7688..403e00d 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1283,10 +1283,14 @@ int drm_mode_getconnector(struct drm_device *dev, void *data, out_resp-connector_id = connector-base.id; out_resp-connector_type = connector-connector_type; out_resp-connector_type_id = connector-connector_type_id; + + /* These values should have been fetched by fill_modes from the EDID */ out_resp-mm_width = connector-display_info.width_mm; out_resp-mm_height = connector-display_info.height_mm; out_resp-subpixel = connector-display_info.subpixel_order; - out_resp-connection = connector-status; + + /* Go see if it's there */ + out_resp-connection = connector-funcs-detect(connector); if (connector-encoder) out_resp-encoder_id = connector-encoder-base.id; else -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12764] Can not ioremap virtual address for G33 hw status page
http://bugzilla.kernel.org/show_bug.cgi?id=12764 --- Comment #1 from r...@sisk.pl 2009-03-07 14:13 --- On Wednesday 04 March 2009, Maciej Rutecki wrote: 2009/3/3 Rafael J. Wysocki r...@sisk.pl: Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12764 Subject : Can not ioremap virtual address for G33 hw status page Submitter : Maciej Rutecki maciej.rute...@gmail.com Date: 2009-02-23 14:46 (9 days old) Problem seems by solved in 2.6.29-rc7 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12764] Can not ioremap virtual address for G33 hw status page
http://bugzilla.kernel.org/show_bug.cgi?id=12764 r...@sisk.pl changed: What|Removed |Added Status|NEW |CLOSED Resolution||CODE_FIX -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12764] New: Can not ioremap virtual address for G33 hw status page
http://bugzilla.kernel.org/show_bug.cgi?id=12764 Summary: Can not ioremap virtual address for G33 hw status page Product: Drivers Version: 2.5 KernelVersion: 2.6.29-rc6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: r...@sisk.pl OtherBugsDependingO 12398 nThis: Regression: 1 Subject: [Linux 2.6.29-rc6] [drm:i915_set_status_page] *ERROR* can not ioremap virtual address for G33 hw status page Submitter : Maciej Rutecki maciej.rute...@gmail.com Date : 2009-02-23 14:46 References : http://marc.info/?l=linux-kernelm=123540053219505w=4 This entry is being used for tracking a regression from 2.6.28. Please don't close it until the problem is fixed in the mainline. Caused by: commit 6fb88588555a18792a27f483887fe1f2af5f9c9b Author: Jesse Barnes jbar...@virtuousgeek.org Date: Mon Feb 23 10:08:21 2009 +1000 drm/i915: fix WC mapping in non-GEM i915 code. [airlied - taken from mailing list posting] Signed-off-by: Dave Airlie airl...@redhat.com First-Bad-Commit : 6fb88588555a18792a27f483887fe1f2af5f9c9b Notify-Also : Eric Anholt e...@anholt.net -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [drm/i915] Move legacy breadcrumb out of the reserved status page area
On Friday, November 7, 2008 5:44 pm Keith Packard wrote: Addresses in the hardware status page below index 0x20 are reserved for use by the hardware. The legacy breadcrumb was sitting at index 5. Move it to index 0x21, and make sure everyone uses the defined value instead of hard-coded constants. Patch looks good... how do bugs like this stay hidden for so long I wonder? Jesse - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [drm/i915] Move legacy breadcrumb out of the reserved status page area
On Fri, Nov 7, 2008 at 8:44 PM, Keith Packard [EMAIL PROTECTED] wrote: Addresses in the hardware status page below index 0x20 are reserved for use by the hardware. The legacy breadcrumb was sitting at index 5. Move it to index 0x21, and make sure everyone uses the defined value instead of hard-coded constants. Just remove it completely? I don't think anything really use it. Kristian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] [drm/i915] Move legacy breadcrumb out of the reserved status page area
Addresses in the hardware status page below index 0x20 are reserved for use
by the hardware. The legacy breadcrumb was sitting at index 5. Move it to
index 0x21, and make sure everyone uses the defined value instead of
hard-coded constants.
Signed-off-by: Keith Packard [EMAIL PROTECTED]
---
drivers/gpu/drm/i915/i915_dma.c | 10 --
drivers/gpu/drm/i915/i915_drv.h |3 ++-
drivers/gpu/drm/i915/i915_irq.c |6 ++
3 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9d4278b..0d215e3 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -445,7 +445,7 @@ static void i915_emit_breadcrumb(struct drm_device *dev)
BEGIN_LP_RING(4);
OUT_RING(MI_STORE_DWORD_INDEX);
- OUT_RING(5 MI_STORE_DWORD_INDEX_SHIFT);
+ OUT_RING(I915_BREADCRUMB_INDEX MI_STORE_DWORD_INDEX_SHIFT);
OUT_RING(dev_priv-counter);
OUT_RING(0);
ADVANCE_LP_RING();
@@ -576,7 +576,7 @@ static int i915_dispatch_flip(struct drm_device * dev)
BEGIN_LP_RING(4);
OUT_RING(MI_STORE_DWORD_INDEX);
- OUT_RING(5 MI_STORE_DWORD_INDEX_SHIFT);
+ OUT_RING(I915_BREADCRUMB_INDEX MI_STORE_DWORD_INDEX_SHIFT);
OUT_RING(dev_priv-counter);
OUT_RING(0);
ADVANCE_LP_RING();
@@ -611,7 +611,6 @@ static int i915_batchbuffer(struct drm_device *dev, void
*data,
struct drm_file *file_priv)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
- u32 *hw_status = dev_priv-hw_status_page;
drm_i915_sarea_t *sarea_priv = (drm_i915_sarea_t *)
dev_priv-sarea_priv;
drm_i915_batchbuffer_t *batch = data;
@@ -637,7 +636,7 @@ static int i915_batchbuffer(struct drm_device *dev, void
*data,
mutex_unlock(dev-struct_mutex);
if (sarea_priv)
- sarea_priv-last_dispatch = (int)hw_status[5];
+ sarea_priv-last_dispatch = READ_BREADCRUMB(dev_priv);
return ret;
}
@@ -645,7 +644,6 @@ static int i915_cmdbuffer(struct drm_device *dev, void
*data,
struct drm_file *file_priv)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
- u32 *hw_status = dev_priv-hw_status_page;
drm_i915_sarea_t *sarea_priv = (drm_i915_sarea_t *)
dev_priv-sarea_priv;
drm_i915_cmdbuffer_t *cmdbuf = data;
@@ -673,7 +671,7 @@ static int i915_cmdbuffer(struct drm_device *dev, void
*data,
}
if (sarea_priv)
- sarea_priv-last_dispatch = (int)hw_status[5];
+ sarea_priv-last_dispatch = READ_BREADCRUMB(dev_priv);
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ad03531..9b5b6dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -616,8 +616,9 @@ static inline void opregion_enable_asle(struct drm_device
*dev) { return; }
* The area from dword 0x20 to 0x3ff is available for driver usage.
*/
#define READ_HWSP(dev_priv, reg) (((volatile
u32*)(dev_priv-hw_status_page))[reg])
-#define READ_BREADCRUMB(dev_priv) READ_HWSP(dev_priv, 5)
+#define READ_BREADCRUMB(dev_priv) READ_HWSP(dev_priv, I915_BREADCRUMB_INDEX)
#define I915_GEM_HWS_INDEX 0x20
+#define I915_BREADCRUMB_INDEX 0x21
extern int i915_wait_ring(struct drm_device * dev, int n, const char *caller);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 683c0f0..9a89667 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -249,12 +249,10 @@ static int i915_emit_irq(struct drm_device * dev)
if (dev_priv-sarea_priv)
dev_priv-sarea_priv-last_enqueue = dev_priv-counter;
- BEGIN_LP_RING(6);
+ BEGIN_LP_RING(4);
OUT_RING(MI_STORE_DWORD_INDEX);
- OUT_RING(5 MI_STORE_DWORD_INDEX_SHIFT);
+ OUT_RING(I915_BREADCRUMB_INDEX MI_STORE_DWORD_INDEX_SHIFT);
OUT_RING(dev_priv-counter);
- OUT_RING(0);
- OUT_RING(0);
OUT_RING(MI_USER_INTERRUPT);
ADVANCE_LP_RING();
--
1.5.6.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17799] New: 855GM dri problem after Initialize hardware status page at device load... change on drm-next
http://bugs.freedesktop.org/show_bug.cgi?id=17799
Summary: 855GM dri problem after Initialize hardware status page
at device load... change on drm-next
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM modules
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
When testing some commits from current drm-next branch from
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git I found a
regression introduced on a machine with 855GM chipset, that I nailed down to
the commit titled i915: Initialize hardware status page at device load when
possible..
To reproduce, you must install kde 4.1 and enable its gfx effects. With gfx
effects enabled you are not able to login into kde after a boot without
switching to vt (when switching to vt and back to X before doing login I
couldn't reproduce).
I did some basic debugging (attaching gdb) and I found that X gets stuck
waiting for something from drm perhaps, may be this can help:
(gdb) n
0xe424 in __kernel_vsyscall ()
(gdb) n
Single stepping until exit from function __kernel_vsyscall,
which has no line number information.
0xe424 in __kernel_vsyscall ()
(gdb) n
Single stepping until exit from function __kernel_vsyscall,
which has no line number information.
SmartScheduleTimer (sig=14) at utils.c:1559
1559{
(gdb) n
0x0806efcf in __i686.get_pc_thunk.cx ()
Current language: auto; currently asm
(gdb) n
Single stepping until exit from function __i686.get_pc_thunk.cx,
which has no line number information.
SmartScheduleTimer (sig=14) at utils.c:1560
1560SmartScheduleTime += SmartScheduleInterval;
Current language: auto; currently c
(gdb) n
1561}
(gdb) n
0xe424 in __kernel_vsyscall ()
utils.c is from xorg-server-1.4.2/os/utils.c
I get this backtrace while inside SmartScheduleTimer:
(gdb) bt
#0 SmartScheduleTimer (sig=14) at utils.c:1559
#1 signal handler called
#2 0xe424 in __kernel_vsyscall ()
#3 0xb7d3f5f9 in ioctl () from /lib/i686/libc.so.6
#4 0xb7abd24c in drmCommandWrite (fd=10, drmCommandIndex=5, data=0xa281bd0,
size=170400720) at xf86drm.c:2307
#5 0xaf709294 in intelWaitIrq (intel=0xa26eda0, seq=3) at intel_ioctl.c:89
#6 0xaf70945f in intelRefillBatchLocked (intel=0xa26eda0, allow_unlock=0 '\0')
at intel_ioctl.c:135
#7 0xaf709ac0 in intelFlushBatchLocked (intel=0xa26eda0, ignore_cliprects=0
'\0', refill=1 '\001', allow_unlock=252 '�')at intel_ioctl.c:291
#8 0xaf709b15 in intelFlushBatch (intel=0xa26eda0, refill=252 '�') at
intel_ioctl.c:297
#9 0xaf709ee7 in intelWaitForIdle (intel=0xa26eda0) at intel_ioctl.c:313
#10 0xaf712b70 in intelUploadTexImages (intel=0xa26eda0, t=0xa55f868, face=0)
at intel_tex.c:812
#11 0xaf7020d1 in i830SetTexImages (i830=0xa26eda0, tObj=0xa55f698) at
i830_texstate.c:251
#12 0xaf702165 in enable_tex_common (ctx=0x40046445, unit=0) at
i830_texstate.c:311
#13 0xaf702405 in i830UpdateTexUnit (ctx=0xa26eda0, unit=0) at
i830_texstate.c:448
#14 0xaf702614 in i830UpdateTextureState (intel=0xa26eda0) at
i830_texstate.c:471
#15 0xaf71fc7b in intelRunPipeline (ctx=0xa26eda0) at intel_tris.c:767
#16 0xaf7adb96 in _tnl_draw_prims (ctx=0xa26eda0, arrays=0xa2a9480,
prim=0xa2a7fdc, nr_prims=1, ib=0x0, min_index=0,max_index=3) at
tnl/t_draw.c:402
#17 0xaf7a6c52 in vbo_exec_vtx_flush (exec=0xa2a7eb8) at
vbo/vbo_exec_draw.c:215
#18 0xaf7a23b1 in vbo_exec_FlushVertices (ctx=0xa26eda0, flags=1) at
vbo/vbo_exec_api.c:700
#19 0xaf837ebc in _mesa_PopAttrib () at main/attrib.c:859
#20 0xb7af5afe in ?? () from /usr/lib/xorg/modules/extensions//libglx.so
#21 0xb7aed6b8 in DoRender () from /usr/lib/xorg/modules/extensions//libglx.so
#22 0xb7aed7eb in ?? () from /usr/lib/xorg/modules/extensions//libglx.so
#23 0xb7af1e8e in ?? () from /usr/lib/xorg/modules/extensions//libglx.so
#24 0x08156267 in XaceCatchExtProc (client=0x9d8f808) at xace.c:299
#25 0x08089743 in Dispatch () at dispatch.c:531
#26 0x0806ec9d in main (argc=-1080974348, argv=0x823b02c, envp=Cannot access
memory at address 0x4004644d
) at main.c:452
--
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 Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of everything?
Ben Gamari wrote: What trees are you pulling from. Pulling from drm/modesetting-gem and mesa/drm-gem I'm getting some pretty obvious build errors (e.g. struct drm_gem_open never defined). That's exactly what I am doing. Upto now I did not experience any of these errors. Cheers, Johannes - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of everything?
On the note of GEM, would it be worth pulling down the GEM trees to play around with and submit bugs against? Is the code in a state at all resembling stable (can you run a moderately standard X session for more than 10 seconds)? I'd be glad to start reporting if so. Thanks, - Ben On Wed, 2008-07-09 at 01:52 +0300, Daniel Stone wrote: Hi, On Wed, Jul 09, 2008 at 12:31:22AM +0300, Maxim Levitsky wrote: Last time I checked modesetting, This works. intel-batchbuffer, This works. dri2, This works. And lastly, just for a thought, maybe it is better to do one thing at time, for example stabilize kernel modesetting, put it in kernel, then release gem driver and stabilize it, and then add dri2 to it? I'm sure the developers working on modesetting, the developers working on GEM, and the developers working on DRI2 (three independent sets of people) would more than appreciate patches, or even specific bug reports they can fix. Short of that, I'm not sure which problem you're actually trying to solve. Cheers, Daniel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of everything?
Ben Gamari wrote: On the note of GEM, would it be worth pulling down the GEM trees to play around with and submit bugs against? Is the code in a state at all resembling stable (can you run a moderately standard X session for more than 10 seconds)? As far as I can tell this is working nearly stable with my intel i945GM. The most annoying thing is that it is only possible to start X.org once. After going back to the framebuffer console it won't display anything again. Regards, Johannes - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of everything?
On Wed, 2008-07-09 at 01:52 +0300, Daniel Stone wrote: I'm sure the developers working on modesetting, the developers working on GEM, and the developers working on DRI2 (three independent sets of people) would more than appreciate patches, or even specific bug reports they can fix. https://bugs.freedesktop.org/show_bug.cgi?id=15477 is a DRI2 related regression reported three months ago but unresolved as of this writing. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Status of everything?
Hi, You may consider this offtopic, but I wondering about status of graphical development. Last time I checked modesetting, intel-batchbuffer, dri2, none did work. So my question is more or less, when to expect new technologies to turn stable? Now it seems that GEM was choosen to be memory manager, I bet that its current state isn't more stable that ttm was. What the status of gallium? And lastly, just for a thought, maybe it is better to do one thing at time, for example stabilize kernel modesetting, put it in kernel, then release gem driver and stabilize it, and then add dri2 to it? What do you think? Wish you best luck, Maxim Levitsky - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of everything?
You may consider this offtopic, but I wondering about status of graphical development. Yes. And lastly, just for a thought, maybe it is better to do one thing at time, for example stabilize kernel modesetting, put it in kernel, then release gem driver and stabilize it, and then add dri2 to it? no. Dave. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of everything?
Hi, On Wed, Jul 09, 2008 at 12:31:22AM +0300, Maxim Levitsky wrote: Last time I checked modesetting, This works. intel-batchbuffer, This works. dri2, This works. And lastly, just for a thought, maybe it is better to do one thing at time, for example stabilize kernel modesetting, put it in kernel, then release gem driver and stabilize it, and then add dri2 to it? I'm sure the developers working on modesetting, the developers working on GEM, and the developers working on DRI2 (three independent sets of people) would more than appreciate patches, or even specific bug reports they can fix. Short of that, I'm not sure which problem you're actually trying to solve. Cheers, Daniel signature.asc Description: Digital signature - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of everything?
On Wed, 2008-07-09 at 00:31 +0300, Maxim Levitsky wrote: And lastly, just for a thought, maybe it is better to do one thing at time, for example stabilize kernel modesetting, put it in kernel, then release gem driver and stabilize it, and then add dri2 to it? Yes, but everything depends on GEM, so that goes first. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI2 status
On Thu, Feb 21, 2008 at 12:33 PM, Tiago Vignatti [EMAIL PROTECTED] wrote: Jerome Glisse escreveu: ... Yes please put DRI2 in separate files so i can import them in gallium without having to mess with older dri interface sitting in gallium right now Also, with DRI2 we have to explicit pass --disable-dri2 flag to autoconf because Xorg uses dri_sarea.h which is external to X server (from mesa). Is this good enough? Nope, these are definitely problems that need to be fixed. Please file bugs, and assign to me, otherwise I'll just forget. I got sucked into a Red Hat black hole shortly after committing the first DRI2 patches, and had to leave them upstream in a rather rough state. Bad timing, but I'm working fixing this stuff now. I recently merged the intel_context.c files for i915 and i965 in mesa, which should add DRI2 for i965, but I'm still testing that. The roadmap to getting DRI2 into a state where we can enable it by default includes: - Implement DRI2 protocol so direct rendering can work. Includes a DRI2 protocol module, protocol code in the DRI2 module in the X server and protocol code in libGL. - Implement DRI2 support in libGL. I want to do this more like how AIGLX works, with a vtable of GLX functions that the glX* functions can call into. There will then be a vtable for indirect, XF86DRI and DRI2. - There's problems with resizing redirected direct rendering windows. - Get the xf86-video-intel intel-batchbuffer branch up to decent performance and merge to master. Not sure what state this is in at this point, but I merged Eric's intel-batchbuffer branch from his repo to the main repo, so all this work is now at least in the same branch. Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915: wrap chipset types requiring hw status set ioctl
On 2008.01.30 10:55:40 +0800, Zhenyu Wang wrote:
Rebase this patch to current drm git tree, and attach patch
to drm-patches kernel tree for 2.6.25 inclusion.
Thanks.
---
[PATCH] i915: wrap chipset types requiring hw status set ioctl
Also applys to recent added new chipset.
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
---
shared-core/i915_dma.c |5 -
shared-core/i915_drv.h |2 ++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/shared-core/i915_dma.c b/shared-core/i915_dma.c
index 3874ed5..9fa4a60 100644
--- a/shared-core/i915_dma.c
+++ b/shared-core/i915_dma.c
@@ -245,7 +245,7 @@ static int i915_initialize(struct drm_device * dev,
dev_priv-vblank_pipe = DRM_I915_VBLANK_PIPE_A;
/* Program Hardware Status Page */
- if (!IS_G33(dev)) {
+ if (!I915_NEED_GFX_HWS(dev)) {
dev_priv-status_page_dmah =
drm_pci_alloc(dev, PAGE_SIZE, PAGE_SIZE, 0x);
@@ -1396,6 +1396,9 @@ static int i915_set_status_page(struct drm_device *dev,
void *data,
drm_i915_private_t *dev_priv = dev-dev_private;
drm_i915_hws_addr_t *hws = data;
+ if (!I915_NEED_GFX_HWS(dev))
+ return -EINVAL;
+
if (!dev_priv) {
DRM_ERROR(called with no initialization\n);
return -EINVAL;
diff --git a/shared-core/i915_drv.h b/shared-core/i915_drv.h
index 4d3ac0a..be7a47e 100644
--- a/shared-core/i915_drv.h
+++ b/shared-core/i915_drv.h
@@ -1239,6 +1239,8 @@ extern int i915_wait_ring(struct drm_device * dev, int n,
const char *caller);
#define IS_MOBILE(dev) (IS_I830(dev) || IS_I85X(dev) || IS_I915GM(dev) || \
IS_I945GM(dev) || IS_I965GM(dev) || IS_IGD_GM(dev))
+#define I915_NEED_GFX_HWS(dev) (IS_G33(dev) || IS_IGD_GM(dev))
+
#define PRIMARY_RINGBUFFER_SIZE (128*1024)
#endif
--
1.5.3.8
[PATCH] i915: wrap chipset types requiring hw status set ioctl
Also applys to recent added new chipset.
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
---
diff --git a/drivers/char/drm/i915_dma.c b/drivers/char/drm/i915_dma.c
index 43986d8..e9d6663 100644
--- a/drivers/char/drm/i915_dma.c
+++ b/drivers/char/drm/i915_dma.c
@@ -171,7 +171,7 @@ static int i915_initialize(struct drm_device * dev, drm_i915_init_t * init)
dev_priv-allow_batchbuffer = 1;
/* Program Hardware Status Page */
- if (!IS_G33(dev)) {
+ if (!I915_NEED_GFX_HWS(dev)) {
dev_priv-status_page_dmah =
drm_pci_alloc(dev, PAGE_SIZE, PAGE_SIZE, 0x);
@@ -720,6 +720,9 @@ static int i915_set_status_page(struct drm_device *dev, void *data,
drm_i915_private_t *dev_priv = dev-dev_private;
drm_i915_hws_addr_t *hws = data;
+ if (!I915_NEED_GFX_HWS(dev))
+ return -EINVAL;
+
if (!dev_priv) {
DRM_ERROR(called with no initialization\n);
return -EINVAL;
diff --git a/drivers/char/drm/i915_drv.h b/drivers/char/drm/i915_drv.h
index 37bbf67..0bb8308 100644
--- a/drivers/char/drm/i915_drv.h
+++ b/drivers/char/drm/i915_drv.h
@@ -1101,6 +1101,8 @@ extern int i915_wait_ring(struct drm_device * dev, int n, const char *caller);
#define IS_MOBILE(dev) (IS_I830(dev) || IS_I85X(dev) || IS_I915GM(dev) || \
IS_I945GM(dev) || IS_I965GM(dev) || IS_IGD_GM(dev))
+#define I915_NEED_GFX_HWS(dev) (IS_G33(dev) || IS_IGD_GM(dev))
+
#define PRIMARY_RINGBUFFER_SIZE (128*1024)
#endif
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] i915: wrap chipset types requiring hw status set ioctl
[PATCH] i915: wrap chipset types requiring hw status set ioctl
Also include hw status setting for recent added new chipset.
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
---
shared-core/i915_dma.c |5 -
shared-core/i915_drv.h |2 ++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/shared-core/i915_dma.c b/shared-core/i915_dma.c
index 287e95a..2f34437 100644
--- a/shared-core/i915_dma.c
+++ b/shared-core/i915_dma.c
@@ -172,7 +172,7 @@ static int i915_initialize(struct drm_device * dev,
drm_i915_init_t * init)
dev_priv-vblank_pipe = DRM_I915_VBLANK_PIPE_A;
/* Program Hardware Status Page */
- if (!IS_G33(dev)) {
+ if (!I915_NEED_GFX_HWS(dev)) {
dev_priv-status_page_dmah =
drm_pci_alloc(dev, PAGE_SIZE, PAGE_SIZE, 0x);
@@ -1304,6 +1304,9 @@ static int i915_set_status_page(struct drm_device *dev,
void *data,
drm_i915_private_t *dev_priv = dev-dev_private;
drm_i915_hws_addr_t *hws = data;
+ if (!I915_NEED_GFX_HWS(dev))
+ return -EINVAL;
+
if (!dev_priv) {
DRM_ERROR(called with no initialization\n);
return -EINVAL;
diff --git a/shared-core/i915_drv.h b/shared-core/i915_drv.h
index 7469515..85b5109 100644
--- a/shared-core/i915_drv.h
+++ b/shared-core/i915_drv.h
@@ -1229,6 +1229,8 @@ extern int i915_wait_ring(struct drm_device * dev, int n,
const char *caller);
#define IS_MOBILE(dev) (IS_I830(dev) || IS_I85X(dev) || IS_I915GM(dev) || \
IS_I945GM(dev) || IS_I965GM(dev) || IS_IGD_GM(dev))
+#define I915_NEED_GFX_HWS(dev) (IS_G33(dev) || IS_IGD_GM(dev))
+
#define PRIMARY_RINGBUFFER_SIZE (128*1024)
#endif
--
1.5.3.7
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Mach64 DRI status
On Sun, 02 Dec 2007 20:59:16 +, José Fonseca wrote: On Fri, 23 Nov 2007 00:27:37 +0100, Pascal Vincent wrote: Hello, can you please indicate the current ATI mach64 DRI status. In fact, http://dri.freedesktop.org/wiki/ATIMach64 page is not so clear so i don't have the clear responses to - is mach64 is now secure ? this means : - is it now included in DRI and Mesa ? (the response seems to be yes) - is mach64 module is now included in kernel ? (it seems not) and if not why ? Tks a lot for clarification Pascal Pascal, I wrote that wiki page several years ago. I never got around to do it, because it involved a non trivial amount of work, and I approached in a naive way (trying to do too many things at the same time, instead of doing gradual changes). I need to reevaluate those statements, especially, concerning the security, and the best way to do it. The mach64 driver has three parts: one in Xorg, another in Mesa, another in the kernel. The unsafe part is the kernel part. And that's probably why is not included in the stock kernel. The reason the mach64 kernel module is unsafe is because it allows an OpenGL application to send malicious commands interspersed with the vertex data. Those malicious commands could give control over the physical memory, and therefore be used to obtain root privileges in theory. The mach64 kernel needs to be changed to verify and copy the data to private memory. Or at least unmap the memory from the client before verifying it and handing to the hardware. Or so I though... I need to verify how much control over the physical memory the client can actually get. As I'm unsure if it is just the memory in the AGP aperture, or the whole memory. If it is just the AGP memory, then there is no risk. José The work to get Mach64 secure was already done by George ( https://bugs.freedesktop.org/show_bug.cgi?id=6242 ). Dave Airlie had concerns with the blits, but I reviewed the code with him I found it to be secure (basically we don't let the client touch dma buffers -- it's not the most efficient way for blits, but is is simple as it doesn't imply maintaining two sets of buffers, one private another public). Now I've cleaned up the code a bit (especially eliminating some macros) and commented more, to make it easier to understand and maintain. Hopefully it will be merged soon. José - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Mach64 DRI status
On Fri, 23 Nov 2007 00:27:37 +0100, Pascal Vincent wrote: Hello, can you please indicate the current ATI mach64 DRI status. In fact, http://dri.freedesktop.org/wiki/ATIMach64 page is not so clear so i don't have the clear responses to - is mach64 is now secure ? this means : - is it now included in DRI and Mesa ? (the response seems to be yes) - is mach64 module is now included in kernel ? (it seems not) and if not why ? Tks a lot for clarification Pascal Pascal, I wrote that wiki page several years ago. I never got around to do it, because it involved a non trivial amount of work, and I approached in a naive way (trying to do too many things at the same time, instead of doing gradual changes). I need to reevaluate those statements, especially, concerning the security, and the best way to do it. The mach64 driver has three parts: one in Xorg, another in Mesa, another in the kernel. The unsafe part is the kernel part. And that's probably why is not included in the stock kernel. The reason the mach64 kernel module is unsafe is because it allows an OpenGL application to send malicious commands interspersed with the vertex data. Those malicious commands could give control over the physical memory, and therefore be used to obtain root privileges in theory. The mach64 kernel needs to be changed to verify and copy the data to private memory. Or at least unmap the memory from the client before verifying it and handing to the hardware. Or so I though... I need to verify how much control over the physical memory the client can actually get. As I'm unsure if it is just the memory in the AGP aperture, or the whole memory. If it is just the AGP memory, then there is no risk. José - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 eGore wrote: I think R300 needs something similar. so far I tried to bundle some things here: http://dri.freedesktop.org/wiki/R300_20Portal - -- Paul Heldens. Accepting PGP/GPG encrypted mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFpP4Ut3z1Au/6XcMRCkTXAJ9zaFFkrLAIJAcUtql0YHsBO5/v8ACgqPE6 HLSi2tmFk/dbTsGuh85eBa8= =Ge9Q -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 status
On 1/10/07, eGore [EMAIL PROTECTED] wrote: Hi list, recently I've read much about the progress on nouveau. They do a good job and also at public relations. One can get the information what is going on from their site and it's quite up to date. I think R300 needs something similar. I would like to help developing this driver so it would be helpfull if there would be a todo list. And a small summary of the progress once in a while. It would be also nice to have a list with known problems/issues, like mesa fallbacks etc. (This could also stop users from posting Driver claims not to support visual XYZ bugs). How do others see this? How do you stay up to date? Does noone else like to see this kind of information? Or am I simply missing the page where all this can be found? I don't want to offend anyone by asking this and especially not anyone who is putting work into R300 or any other driver development. But I personally like the small stories behind a piece of software. Also: The increased publicity could attrack developers that like to see their names in a monthly summary ;-) Regards, Christoph Brill -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer Hi, I guess that maybe it's time to start somethings like nouveau to bring in more people to work on this. So far i haven't think of any better name than ardent this is french sailing word for a boat which have tendency to go upwind. I got no idea that involve A, M and D. best, Jerome Glisse - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 status
Jerome Glisse írta: On 1/10/07, eGore [EMAIL PROTECTED] wrote: Hi list, recently I've read much about the progress on nouveau. They do a good job and also at public relations. One can get the information what is going on from their site and it's quite up to date. I think R300 needs something similar. I would like to help developing this driver so it would be helpfull if there would be a todo list. And a small summary of the progress once in a while. It would be also nice to have a list with known problems/issues, like mesa fallbacks etc. (This could also stop users from posting Driver claims not to support visual XYZ bugs). How do others see this? How do you stay up to date? Does noone else like to see this kind of information? Or am I simply missing the page where all this can be found? I don't want to offend anyone by asking this and especially not anyone who is putting work into R300 or any other driver development. But I personally like the small stories behind a piece of software. Also: The increased publicity could attrack developers that like to see their names in a monthly summary ;-) Regards, Christoph Brill -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer Hi, I guess that maybe it's time to start somethings like nouveau to bring in more people to work on this. So far i haven't think of any better name than ardent this is french sailing word for a boat which have tendency to go upwind. I got no idea that involve A, M and D. best, Jerome Glisse But Ati is a nickname in Hungarian for Atilla, surely most of you know a famous conqueror with this name. ;-) And I am willing to test any new drivers on my Xpress 200M based notebook... Best regards, Zoltán Böszörményi - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 status
Am Mittwoch, den 10.01.2007, 15:54 +0100 schrieb Paul Heldens: http://dri.freedesktop.org/wiki/R300_20Portal I think it's a good idea but it's really hidden. And lacks content ... a bit ;-) But it's a good start. I'm willing to fill it with more information... is it available in an aggregated form, or do I have to gather things from watch git? What about a monthly Git changes for R300 on that page? Regards, Christoph - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 benchmark, rough compatibility list, status, config
Hi, I updated the wiki a bit for R300 a while ago, the fairly complete quake3 benchmark may interest devs and users alike. Please add your own experiences. The configuration indicated with *** in my quake3 benchmark is the most speedy without getting hardlocks for me. Benchmark: http://dri.freedesktop.org/wiki/R300%20Benchmark Compat List: http://dri.freedesktop.org/wiki/R300%20Application Config: http://dri.freedesktop.org/wiki/ATIRadeon#head-8851142da56fd885ce668a165b33fee7003e858d Attempt to concentrate this: http://dri.freedesktop.org/wiki/R300_20Portal - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 benchmark, rough compatibility list, status, config
Am Dienstag, 12. September 2006 15:21 schrieb Paul Heldens: Attempt to concentrate this: http://dri.freedesktop.org/wiki/R300_20Portal Very good, could someone provide a big link from the old r300.sf.net-page to it? (or just remove that and forward?) I think that's still the place were many people are looking for infos. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber: [EMAIL PROTECTED] pgphyuJmFtn59.pgp Description: PGP signature - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 benchmark, rough compatibility list, status, config
Hi Paul Heldens írta: Hi, I updated the wiki a bit for R300 a while ago, the fairly complete quake3 benchmark may interest devs and users alike. Please add your own experiences. The configuration indicated with *** in my quake3 benchmark is the most speedy without getting hardlocks for me. Benchmark: http://dri.freedesktop.org/wiki/R300%20Benchmark Compat List: http://dri.freedesktop.org/wiki/R300%20Application would you please create a hardware/driver compat list, too? I mean, at present, I am running a dual-seat machine with two Radeons, one AGP8x 9200SE and one PCI 7000VE. They are running great, I am using Option VGAAccess off cmdline option -sharevts and the evdev driver to run two different X servers on the two cards, two independent keyboards and mice. What I would like to see in the compat list is which combinations of cards can run with which combinations of drivers. Obviously from my example, r100 and r200 can run together, both are DRI enabled. The problem is the load on the PCI bus when two kids play SuperTux simultaneously, everything is slow if something heavy is running on the PCI Radeon, because disc accesses has to race with the display output. I would like to see a test where a disk benchmark is run while one and both cards are loaded with heavy memory moves. SuperTux in SDL / OpenGL mode is fine. :-) Best regards, Zoltán Böszörményi Config: http://dri.freedesktop.org/wiki/ATIRadeon#head-8851142da56fd885ce668a165b33fee7003e858d Attempt to concentrate this: http://dri.freedesktop.org/wiki/R300_20Portal - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of X600 (5B62) support inquiry; bug 5413
On 03/15/2006 04:01:30 AM, Mike Mestnik wrote: --- Pawel Salek [EMAIL PROTECTED] wrote: [snip] Was working fine for me, until trying to use a newer snapshot. I still need to patch drm_pciids.txt and copy over the /scripts dir before ./install.sh 1. you do not need to copy over /scripts - modify drm_pciids.h directly instead: The makefiles won't try to rebuild it then. Of course, the drm_pciids.txt should be eventually modified in CVS so that no manual modification is required. 2. I confirm that something got broken between 20060306 and 20060308. With any recent snapshot like 20060313, I get: $ glxgears *WARN_ONCE* File r300_ioctl.c function r300Clear line 555 CB_DPATH has been enabled. Please let me know if this introduces new instabilities. *** drmRadeonCmdBuffer: -22 (exiting) and following stuff in dmesg: [drm] Initialized radeon 1.24.0 20060225 on minor 0: [drm] Setting GART location based on new memory map [drm] Loading R300 Microcode [drm] writeback test succeeded in 1 usecs [drm] Setting GART location based on new memory map [drm] Loading R300 Microcode [drm] writeback test succeeded in 1 usecs [drm:r300_emit_3d_load_vbpntr] *ERROR* Offset failed range check (k=0 i=2) while processing 3D_LOAD_VBPNTR packet. [drm:r300_emit_packet3] *ERROR* r300_emit_raw_packet3 failed [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet3 failed Pawel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of X600 (5B62) support inquiry; bug 5413
--- Pawel Salek [EMAIL PROTECTED] wrote: Hi, (Q1) Can anybody summarize shortly what's the status of X600 (PCIID: 5B62, PCIE RV370 type card) support? I see its PCIID is still absent in shared-core/drm_pciids.txt in spite of few success reports: http://sourceforge.net/mailarchive/message.php?msg_id=14645441 (BSD) http://sourceforge.net/mailarchive/message.php?msg_id=14281693 (Linux) The latter message is related to https://bugs.freedesktop.org/show_bug.cgi?id=5413 - I am not sure whether the patch 4547 attached to this report (Q2) should be considered a cleanup or vital for the X600 support? Is it believed that this patch should make X600 work with linux? For what is worth, I tried just appending the id to shared-core/drm_pciids.txt and compiling it on the bleeding edge FC5t3 (after disabling module signing and replacing the kernel drm code by the one available in CVS freedesktop.org), and all I got was few drm messages: [drm] Initialized drm 1.0.1 20051102 [drm] Initialized radeon 1.23.0 20060225 on minor 0: [drm] Setting GART location based on old memory map [drm] Loading R300 Microcode [drm] writeback test succeeded in 1 usecs and a hang (the log messages were saved thanks to remote logging). Can anybody, please, answer Q1 and Q2, and comment on the hang? I would try the binary snapshots to make sure I build drm right but the snapshots obviously do not support this PCIID. Was working fine for me, until trying to use a newer snapshot. I still need to patch drm_pciids.txt and copy over the /scripts dir before ./install.sh Pawel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of X600 (5B62) support inquiry; bug 5413
For Q1, the status is that it should work, but apparently it locks up for some unknown reason for some people. There was a significant fix for potential lockup problems in the radeon ddx driver in xorg modular cvs, which may or not help you. You should try the snapshots, you can try patching the drm that comes with them or use your own, there is not much you can do to build it wrong. Which gets us to Q2, that patch 4745 is needed for drm/dri (and dma ddx) support of new radeons (it is nothing more than new ids, all the cleanup was commited), but it's not in cvs because it sometimes causes lockups (even though the lockups aren't exactly caused by drm, but xorg ddx if it uses the drm module). (Note though that the ids of new radeons already present in drm are just as likely to cause lockups as those which aren't.) There are more fixes comming into the DDX everyday or so too :) So if it doesn't work, you may want to lurk at the CVS commit list and retry regulary. Ben. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status
Kristoffer wrote: I'm thinking of trying the radeon driver again, but i'm wondering wether or not it will ever catch up with the fglrx driver on speed? You worry about speed, I wonder if it ever will catch up with software rendering on stability. Graphichs acceleration, (and the occational prerelease kernel) is the only that ever crash my machines. And yes, I use sw rendering on any machine that have an occational hang. In either case, blame it on lack of documentation. Helge Hafting --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status
On Fri, 2006-01-27 at 08:47 +0100, Helge Hafting wrote: Kristoffer wrote: I'm thinking of trying the radeon driver again, but i'm wondering wether or not it will ever catch up with the fglrx driver on speed? You worry about speed, I wonder if it ever will catch up with software rendering on stability. Graphichs acceleration, (and the occational prerelease kernel) is the only that ever crash my machines. And yes, I use sw rendering on any machine that have an occational hang. In either case, blame it on lack of documentation. I'll agree that this explains some stability issues, but IME performance is usually more a matter of the engineering effort spent on driver optimizations that aren't necessarily hardware specific. YMMV. -- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
status
I'm thinking of trying the radeon driver again, but i'm wondering wether or not it will ever catch up with the fglrx driver on speed? what's the status of this, or goal? and what's the status on 9800 pro dual monitor support with 3d? thanks for all your hard work anyway. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status
On Wed, 25 Jan 2006 11:51:17 +0100 Kristoffer [EMAIL PROTECTED] wrote: I'm thinking of trying the radeon driver again, but i'm wondering wether or not it will ever catch up with the fglrx driver on speed? what's the status of this, or goal? and what's the status on 9800 pro dual monitor support with 3d? thanks for all your hard work anyway. my guess is that you're going to get either silence from the list, or a answer to your own question by doing benchmarks-type response. the only thing I can say is that fglrx is better than dri on some aspects of GL, unfortunatly this is what is used in UT2K3 / UT2K4 for example. there are plans to fix this, as time allows. khaqq --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status
On Wed, 25 Jan 2006 20:29:05 +0100 khaqq [EMAIL PROTECTED] wrote: On Wed, 25 Jan 2006 11:51:17 +0100 Kristoffer [EMAIL PROTECTED] wrote: I'm thinking of trying the radeon driver again, but i'm wondering wether or not it will ever catch up with the fglrx driver on speed? what's the status of this, or goal? and what's the status on 9800 pro dual monitor support with 3d? thanks for all your hard work anyway. my guess is that you're going to get either silence from the list, or a answer to your own question by doing benchmarks-type response. the only thing I can say is that fglrx is better than dri on some aspects of GL, unfortunatly this is what is used in UT2K3 / UT2K4 for example. there are plans to fix this, as time allows. The ut2k4 problem(s) have been in a semi-fixed state for a while now. Bits and bolts dealing with it arent just enabled by default because quite a few changes are needed to get it fully transparent. Couple shots: http://www.rasterburn.org/~aet/ut2k4_tweaked.png http://www.rasterburn.org/~aet/ut2k4_vanilla.png -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status
On Wednesday 25 January 2006 19:01, Aapo Tahkola wrote: On Wed, 25 Jan 2006 20:29:05 +0100 khaqq [EMAIL PROTECTED] wrote: On Wed, 25 Jan 2006 11:51:17 +0100 Kristoffer [EMAIL PROTECTED] wrote: I'm thinking of trying the radeon driver again, but i'm wondering wether or not it will ever catch up with the fglrx driver on speed? what's the status of this, or goal? and what's the status on 9800 pro dual monitor support with 3d? thanks for all your hard work anyway. my guess is that you're going to get either silence from the list, or a answer to your own question by doing benchmarks-type response. the only thing I can say is that fglrx is better than dri on some aspects of GL, unfortunatly this is what is used in UT2K3 / UT2K4 for example. there are plans to fix this, as time allows. The ut2k4 problem(s) have been in a semi-fixed state for a while now. Bits and bolts dealing with it arent just enabled by default because quite a few changes are needed to get it fully transparent. Couple shots: http://www.rasterburn.org/~aet/ut2k4_tweaked.png http://www.rasterburn.org/~aet/ut2k4_vanilla.png Do these fixes remove the need to disable s3tc to avoid the flickering tiling problem? And just a general warning to the original writer of the original question about the r300 driver on 9800 hardware: there are problems with pretty regular lockups. Other r300 hardware (X700, X800, for example) don't seem to have this issue, though. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status
On Wed, 25 Jan 2006 17:28:17 -0500 Adam K Kirchhoff [EMAIL PROTECTED] wrote: On Wednesday 25 January 2006 19:01, Aapo Tahkola wrote: On Wed, 25 Jan 2006 20:29:05 +0100 khaqq [EMAIL PROTECTED] wrote: On Wed, 25 Jan 2006 11:51:17 +0100 Kristoffer [EMAIL PROTECTED] wrote: I'm thinking of trying the radeon driver again, but i'm wondering wether or not it will ever catch up with the fglrx driver on speed? what's the status of this, or goal? and what's the status on 9800 pro dual monitor support with 3d? thanks for all your hard work anyway. my guess is that you're going to get either silence from the list, or a answer to your own question by doing benchmarks-type response. the only thing I can say is that fglrx is better than dri on some aspects of GL, unfortunatly this is what is used in UT2K3 / UT2K4 for example. there are plans to fix this, as time allows. The ut2k4 problem(s) have been in a semi-fixed state for a while now. Bits and bolts dealing with it arent just enabled by default because quite a few changes are needed to get it fully transparent. Couple shots: http://www.rasterburn.org/~aet/ut2k4_tweaked.png http://www.rasterburn.org/~aet/ut2k4_vanilla.png Do these fixes remove the need to disable s3tc to avoid the flickering tiling problem? These changes are already in cvs with exception of fb vbos(pretty useless anyways) and the drm scratch patch. s3tc problem is still there im afraid. Im using patches off #5353 to get around the texture swapping problem... -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of Xpress chips support
I played with the latest CVS version some last week and managed to get X to at least start with DRI enabled on the radeon driver. It doesn't start any applications, and if I leave it alone long enough it goes to a black screen and soft-locks; killing X hard-locks. Attached is the log, or at least, the interesting part of it. The last four lines repeat several hundred thousand times in the full log. ;) I was unable to repeat the hard-lock condition with debugging enabled, unfortunately. I hope this helps. Dec 23 14:29:23 snorlax [drm] Initialized drm 1.0.1 20051102 Dec 23 14:29:23 snorlax [drm:drm_init] Dec 23 14:29:23 snorlax [drm:drm_get_dev] Dec 23 14:29:23 snorlax [drm:radeon_driver_load] PCIE card detected Dec 23 14:29:23 snorlax [drm:drm_ctxbitmap_next] drm_ctxbitmap_next bit : 0 Dec 23 14:29:23 snorlax [drm:drm_ctxbitmap_init] drm_ctxbitmap_init : 0 Dec 23 14:29:23 snorlax [drm:drm_get_head] Dec 23 14:29:23 snorlax [drm:drm_get_head] new minor assigned 0 Dec 23 14:29:23 snorlax [drm] Initialized radeon 1.20.0 20050911 on minor 0: Dec 23 14:29:23 snorlax [drm:drm_stub_open] Dec 23 14:29:23 snorlax [drm:drm_open_helper] pid = 5392, minor = 0 Dec 23 14:29:23 snorlax [drm:radeon_driver_open] Dec 23 14:29:23 snorlax [drm:drm_addmap_core] offset = 0xb010, size = 0x0001, type = 1 Dec 23 14:29:23 snorlax [drm:drm_addmap_core] offset = 0xc000, size = 0x1000, type = 0 Dec 23 14:29:23 snorlax [drm:drm_addmap_core] offset = 0x, size = 0x2000, type = 2 Dec 23 14:29:23 snorlax [drm:drm_addmap_core] 8192 13 c2017000 Dec 23 14:29:23 snorlax [drm:drm_setup] Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0106401, nr=0x01, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0106401, nr=0x01, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_addmap_core] offset = 0x, size = 0x2000, type = 2 Dec 23 14:29:23 snorlax [drm:drm_mmap] start = 0x2aaab14dc000, end = 0x2aaab14de000, offset = 0x1000 Dec 23 14:29:23 snorlax [drm:drm_vm_open] 0x2aaab14dc000,0x2000 Dec 23 14:29:23 snorlax [drm:drm_do_vm_shm_nopage] shm_nopage 0x2aaab14dc000 Dec 23 14:29:23 snorlax [drm:drm_do_vm_shm_nopage] shm_nopage 0x2aaab14dd000 Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_addmap_core] offset = 0xc000, size = 0x03ef8000, type = 0 Dec 23 14:29:23 snorlax [drm:drm_addmap_core] Matching maps of type 0 with mismatched sizes, (66027520 vs 268435456) Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0106426, nr=0x26, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0106426, nr=0x26, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0406400, nr=0x00, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0406400, nr=0x00, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0x40106438, nr=0x38, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_sg_alloc] drm_sg_alloc Dec 23 14:29:23 snorlax [drm:drm_sg_alloc] sg size=8388608 pages=2048 Dec 23 14:29:23 snorlax [drm:drm_sg_alloc] sg alloc handle = 10265200 Dec 23 14:29:23 snorlax [drm:drm_sg_alloc] sg alloc virtual = c20010269000 Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_addmap_core] offset = 0x, size = 0x00101000, type = 4 Dec 23 14:29:23 snorlax [drm:drm_mmap] start = 0x2aaab14de000, end = 0x2aaab15df000, offset = 0x10001000 Dec 23 14:29:23 snorlax [drm:drm_vm_open] 0x2aaab14de000,0x00101000 Dec 23 14:29:23 snorlax [drm:drm_do_vm_sg_nopage] Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_addmap_core] offset = 0x00101000, size = 0x1000, type = 4 Dec 23 14:29:23 snorlax [drm:drm_mmap] start = 0x2aaab15df000, end = 0x2aaab15e, offset = 0x10002000 Dec 23 14:29:23 snorlax [drm:drm_vm_open] 0x2aaab15df000,0x1000 Dec 23 14:29:23 snorlax [drm:drm_do_vm_sg_nopage] Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_addmap_core] offset = 0x00102000, size = 0x0020, type = 4 Dec 23 14:29:23 snorlax [drm:drm_mmap] start = 0x2aaab15e, end = 0x2aaab17e, offset = 0x10003000 Dec 23 14:29:23 snorlax [drm:drm_vm_open] 0x2aaab15e,0x0020 Dec 23 14:29:23 snorlax [drm:drm_do_vm_sg_nopage] Dec 23 14:29:23 snorlax [drm:drm_ioctl] pid=5392, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 Dec 23 14:29:23 snorlax [drm:drm_addmap_core] offset = 0x00302000,
Re: Status of Xpress chips support
Alex Deucher wrote: On 12/24/05, Dave Jones [EMAIL PROTECTED] wrote: On Fri, Dec 23, 2005 at 11:20:34PM +, Dave Airlie wrote: Anyhow, I was wanting to volunteer my services and my Radeon Xpress 200M for development work on this project. I have some kernel hacking/driver development experience, but that was on a device with open specifications, so I wanted to ask the following questions: 1) What do we currently know about these chipsets? They have no on-board RAM and are PCI Express I'm not entirely sure that's correct. Santa brought me a laptop which gives me the option of using the onboard video ram, system ram, or even both. I've not had chance to play with it much yet though. Some of the new XPRESS chips have mixed on-board/system configurations. There are supposedly desktop versions with mixed ram types as well. on the xpress chips, it's called sideport. It can apparently do local/system ram accesses interleaved, though I've no idea how it works (maybe per-tile access, half the tiles local half not?). The other possible modes (i.e. uma only, sideport mem only, or sideport + uma but not interleaved) look simpler. On the desktop chips (at least for the old 3-letter Xxyz chips) it's called hypermemory. As far as I can tell though those chips can't do interleaved accesses, and I don't think there's anything different to the non-hypermemory cards whatsoever (except they have less ram on a half-as wide bus). At least all r300 based chips should be able to render to system memory directly already. Roland --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of Xpress chips support
On 12/24/05, Dave Jones [EMAIL PROTECTED] wrote: On Fri, Dec 23, 2005 at 11:20:34PM +, Dave Airlie wrote: Anyhow, I was wanting to volunteer my services and my Radeon Xpress 200M for development work on this project. I have some kernel hacking/driver development experience, but that was on a device with open specifications, so I wanted to ask the following questions: 1) What do we currently know about these chipsets? They have no on-board RAM and are PCI Express I'm not entirely sure that's correct. Santa brought me a laptop which gives me the option of using the onboard video ram, system ram, or even both. I've not had chance to play with it much yet though. Some of the new XPRESS chips have mixed on-board/system configurations. There are supposedly desktop versions with mixed ram types as well. Alex Dave --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Status of Xpress chips support
Hey all. This is my first time sending to a public mailing list, so don't eat me alive, please. :) Anyhow, I was wanting to volunteer my services and my Radeon Xpress 200M for development work on this project. I have some kernel hacking/driver development experience, but that was on a device with open specifications, so I wanted to ask the following questions: 1) What do we currently know about these chipsets? 2) What more information do I need to bring this aspect of the driver up to par with the older cards/chipsets? 3) How do I go about gathering this information? Thanks for your help and the great work, and I hope I can be of some help. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of Xpress chips support
Anyhow, I was wanting to volunteer my services and my Radeon Xpress 200M for development work on this project. I have some kernel hacking/driver development experience, but that was on a device with open specifications, so I wanted to ask the following questions: 1) What do we currently know about these chipsets? They have no on-board RAM and are PCI Express, as I did the radeon PCIE support and I had to put certain things in on-board RAM, I'm unsure how these chips work, you could see if you can get fglrx working, then you could use hw_script from somewhere on r300.sf.net and the scripts from http://cvs.sourceforge.net/viewcvs.py/r300/r300_driver/hw_scripts/ to give me the info on what way the chip is configured.. 2) What more information do I need to bring this aspect of the driver up to par with the older cards/chipsets? 3) How do I go about gathering this information? Thanks for your help and the great work, and I hope I can be of some help. Maybe with the info above it would be possible to change the X.org DDX to at least allow the card to use the DRM... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of Xpress chips support
On Fri, Dec 23, 2005 at 11:20:34PM +, Dave Airlie wrote: Anyhow, I was wanting to volunteer my services and my Radeon Xpress 200M for development work on this project. I have some kernel hacking/driver development experience, but that was on a device with open specifications, so I wanted to ask the following questions: 1) What do we currently know about these chipsets? They have no on-board RAM and are PCI Express I'm not entirely sure that's correct. Santa brought me a laptop which gives me the option of using the onboard video ram, system ram, or even both. I've not had chance to play with it much yet though. Dave --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 Status Report - Gentoo amd64, Saphire 9600
Hamie schrieb: One other funny I noticed that I've never noticed before without the r300 drivers is that X would 'reload' itself whenever the client closed.. (I was only runnning one at a time, no window manager). Is that normal? It is. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 Status Report - Gentoo amd64, Saphire 9600
Hamie wrote: Hi. A quick status report/feedback on how the r300 effort fares on my workstation. Hardware is an AMD64 3200 (Socket 939, on an Asus A8V Deluxe Motherboard). 1GB RAM dual channeled (2x 512MB sticks) and a Saphire Radeon 9600 card (Mobility Radeon 9600 M10 - PCI ID 1002,4e51). Todays CVS works, yesterdays didn't... I belive it's the 64bit/32boit IOCTL's that were posted today or late yesterday that did the trick there. Up till now I'd either get a complete hang, or (Last night) X would start show a black screen with the movable cursor nothing more. No keyboard access at all no displaying anything else). Today it goes a lot better. X actually starts correctly, and I can bring up an xterm, glxinfo runs (But still says no direct rendering, Xorg.0.log says different) and glxgears now gives a result of 739fps (Default size) vs 270fps using the default non dri setup. (Which still looks a bit slow to me... My 1.6GHz Pentium-M laptop with a FireGL-T2-128 can get ~300fps, I expected more from an Athlon 64 AGP8... Anyway). Things now work... Although I did expect better frame rates. Especially since other have reported much much higher ones... My config log are appended below if anyone else is interested in duplicating/criticising what I've got. One other funny I noticed that I've never noticed before without the r300 drivers is that X would 'reload' itself whenever the client closed.. (I was only runnning one at a time, no window manager). Is that normal? Ahem... Brain fade... Damned thing wasn't picking up the new GL libs r300_dri.so... I found a couple of problems... 1. Gentoo seems to install the libs dri modules for X in /usr/lib/modules/dri instead of under /usr/X11R6 2. The Mesa cvs I have doesn't seem to copy r300_dri.so from $BASE/lib64... In fact the install script just does a cp $BASE/lib*/lib to the destination lib directory. WHich misses r300_dri.so because it's in $BASE/lib64, and NOT in a sub-directory... Maybe I did somethign wrong when I set it up... I'd better check the readme's again. Anway... Now I get ~1080fps in glxgears and tuxracer is actually playable... But the ice is as others have reported black with strange swirly bits on it now again... --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 Status Report - Gentoo amd64, Saphire 9600
Philipp Klaus Krause wrote: Hamie schrieb: One other funny I noticed that I've never noticed before without the r300 drivers is that X would 'reload' itself whenever the client closed.. (I was only runnning one at a time, no window manager). Is that normal? It is. Right. Ta... I've never actually tried running it like that, so wasn't sure... Anyway... Results were much better once I'd got the r300_dri.so actually copied the libs loaded from the correct place... --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 Status Report - Gentoo amd64, Saphire 9600
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hamie wrote: | 1. Gentoo seems to install the libs dri modules for X in | /usr/lib/modules/dri instead of under /usr/X11R6 Sure, but if you don't have a broken install, /usr/X11R6 symlinks to /usr so you won't notice. The usual problem is more like installing opengl stuff to /usr/lib/opengl/implementation. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCL3n/XVaO67S1rtsRAqU9AKCENCi2LPlIG34OuF2p+PYY9Sfa8gCfcuRt +Tf6L3giS6y5RUXhe+qAVKk= =h1wy -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 status
Am 22.01.2005 05:18:55 schrieb(en) Vladimir Dergachev: Just an update on what is going on with R300 driver along with some TODOs in case anyone would have a bit of spare time this weekend and wants to play with R300 (or later) cards: [...] Thanks! Last week I bought a Samsung P35 with Radeon 9600/9700 chip. I won't find time this weekend .. but hopefully in the next few weeks. best regards, Andreas Stenglein --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 status
On Sat, 22 Jan 2005, Andreas Stenglein wrote: Am 22.01.2005 05:18:55 schrieb(en) Vladimir Dergachev: Just an update on what is going on with R300 driver along with some TODOs in case anyone would have a bit of spare time this weekend and wants to play with R300 (or later) cards: [...] Thanks! Last week I bought a Samsung P35 with Radeon 9600/9700 chip. I won't find time this weekend .. but hopefully in the next few weeks. Cool ! E-mail me your SourceForge handle before you start playing with the code so I can add you to the developers list - this will give you access to the CVS and webpage and, in particular, let you download the most recent CVS (anonymous SF CVS is up to a day old). best Vladimir Dergachev best regards, Andreas Stenglein --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 status
Vladimir Dergachev wrote: * BIG TODO: write pixel and vertex shader generator code. This code would need to create vertex and pixel shaders based on the current state of GL context. It might be collection of general shaders for different configuration (Gourad versus flat versus multitexturing, etc) or it could be a compiler that joins together pieces of code. What the driver does now is choose between two sets of shaders: flat color if no textures are used and simple single texture shader without alpha blending if textures are used. The best bet would be to write some general purpose code to convert fixed-function code to a vertex / fragment program. I know at one point 3dlabs was working on code to generate GLSL code from fixed-function state, but I don't know what ever happened to that (or if they intended to release the source). Since at least the r300 and i915 driver (and pretty much all future drivers!) would make use of this, making it fully general is the most forward-looking approach. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 status
On Sat, 22 Jan 2005, Ian Romanick wrote: Vladimir Dergachev wrote: * BIG TODO: write pixel and vertex shader generator code. This code would need to create vertex and pixel shaders based on the current state of GL context. It might be collection of general shaders for different configuration (Gourad versus flat versus multitexturing, etc) or it could be a compiler that joins together pieces of code. What the driver does now is choose between two sets of shaders: flat color if no textures are used and simple single texture shader without alpha blending if textures are used. The best bet would be to write some general purpose code to convert fixed-function code to a vertex / fragment program. I know at one point 3dlabs was working on code to generate GLSL code from fixed-function state, but I don't know what ever happened to that (or if they intended to release the source). Since at least the r300 and i915 driver (and pretty much all future drivers!) would make use of this, making it fully general is the most forward-looking approach. I would agree, except that it doubles the work for R300 driver - one would need to write both the translator to vertex/fragment programs and the compiler of said programs. And it will not necessarily be faster.. Perhaps an intermediate approach - write code that would yield to easy future generalization ? Btw, do you know any details of how i915 platform describes vertex/pixel shaders in hardware ? thank you ! Vladimir Dergachev --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 status
Just an update on what is going on with R300 driver along with some TODOs in case anyone would have a bit of spare time this weekend and wants to play with R300 (or later) cards: * coordinates upload and allocation of input registers (to vertex processor) work. This means that whatever the configuration of TNL pipeline all the data that needs to be uploaded to the chip will be uploaded (regardless of current vertex and pixel shader status) TODO: convert r300_render.c from uploading vertices via command buffer to using vertex buffer in video memory, which should speed things up considerably. * blending and stencil processing code is in place, with one caveat: we don't know how to enable stencil buffer. There should be a bit in some register that does this. TODO: find out the stencil enable bit (Possibly in one of ZS registers ?) * texture processing and drawing works, modulo BIG TODO. * BIG TODO: write pixel and vertex shader generator code. This code would need to create vertex and pixel shaders based on the current state of GL context. It might be collection of general shaders for different configuration (Gourad versus flat versus multitexturing, etc) or it could be a compiler that joins together pieces of code. What the driver does now is choose between two sets of shaders: flat color if no textures are used and simple single texture shader without alpha blending if textures are used. * the driver is stable with most programs I tried it with, modulo the fact that it hangs when quake starts a game or when tuxracer starts a race. best Vladimir Dergachev --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Status of Mach64?
I'm following DRI devel the mailing lists and have not seen anything on the Mach64 driver lately, especially on the security issues. Any progress? Is Mach64 in Xorg-6.8.1? I'm running Debian with XFree86-4.3.0 and self compiled xlibmesa-dri xserver-xfree86 packages. Unless the switch to X.org includes a fully supported driver, I will not change before Debian unstable does. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of Mach64?
I'm following DRI devel the mailing lists and have not seen anything on the Mach64 driver lately, especially on the security issues. Any progress? Is Mach64 in Xorg-6.8.1? I'm running Debian with XFree86-4.3.0 and self compiled xlibmesa-dri xserver-xfree86 packages. Unless the switch to X.org includes a fully supported driver, I will not change before Debian unstable does. well I was semi-committed to fixing this and adding some features to the mach64 ddx, but mach64 laptop display died on me, and the simple cable replacement didn't work so I suspect the inverter is bust... I might be able to get it fixed, but it'll take a while and even then mach64 is down my list of things.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 status
Just an update on what has been happening with R300 CVS: r300_demo: * several new test modes are available: + --vb-triangles - paint triangles using vertex buffer [WORKS] + --immd-triangles - paint triangles using immediate data [BROKEN] (paints but locks up) + --idx-triangles - paint triangles using data in vertex buffer with vertices specified by embedded indices [WORKS] * changed r300_lib.[c,h] files to be more portable and ease inclusion in other code. r300_driver/drm: * two new commands: + end32 - for stabilizing engine after 3d rendering (to prevent lockups) + packet3_raw - for passing several packet3's directly to the engine r300_driver/r300 * wrote glue to include r300_lib.[c,h] into the driver code * added code to paint QUAD primitives with flat colors. Pretty basic, but no lockups :) Note: no transform is done yet so glxgears displays static (non-moving) gear teeth. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] r300_demo status
On Tue, 21 Dec 2004, Vladimir Dergachev wrote: r300_demo status: * I double checked and r300_demo works fine on my computer (Mobility M10) with DRM from DRI CVS (radeon_drv version 1.13.0) * I have added a test mode for drawing using vertex buffers. It draws some triangles, without lockups but in dark blue color instead of random one as it was supposed to be. Help on figuring this out would be much appreciated ! Update: color works too now. I forgot one bitfield. thank you ! Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
On Wed, Dec 01, 2004 at 01:11:48PM +0100, Felix Khling wrote: Am Mi, den 01.12.2004 schrieb Adam Jackson um 5:27: On Monday 29 November 2004 17:03, Felix Khling wrote: There is no dri.freedesktop.org yet. I think there is no need for a redirect. The current place is already different from where it was before the break-in (used to be in ~dri/snapshots now it's in dri/snapshots). If you could setup a dri.freedesktop.org that would be great. Maybe we could move our Wiki from sourceforge to the new location. Ajax, are you reading this? What do you think about upgrading to a newer MoinMoin version with ACLs while we're at it. I wasn't reading, sorry, I was blissfully afk over the holiday. The moinmoin version on fd.o is a good one, so we should be able to just copy our old wiki over. I'll see if I can't hit this before I skip town again. I'd like to do that. I sent an email (below) to concerning this to [EMAIL PROTECTED], but never got reply. We needs CGI exec permission on fdo/~dri. What about Jos's modifications? How important are they and how difficult would it be to port them to the new version? It's a small patch. I'll do that, once it's running. They just modify the rules for WikiNames (so that S3, DRI, and other acronyms match), and also integrate with the doxygen (so that Mesa/DRM functions also match.) Regards, Jos Fonseca - Forwarded message from Jos Fonseca [EMAIL PROTECTED] - Date: Mon, 25 Oct 2004 13:37:33 +0100 From: Jos Fonseca [EMAIL PROTECTED] Subject: CGI for DRI project To: [EMAIL PROTECTED] Hi, I'm one of the developers of the DRI project, and I'm considering moving the DRI MoinMoin Wiki from Sourceforge from http://dri.sourceforge.net/cgi-bin/moin.cgi/ to freedesktop.org . Sourceforge has an old python version and that has restrained the MoinMoin version we can run. The Wiki has some custom python code to hyperlink keywords from the source doxygen documentation so there would be added benefit if this was all integrated in the same machine. There is no CGI permissions for either users or projects. Could you please enable CGI on /projects/*/public_html/cgi-bin or something like that? Thanks, Jos Fonseca - End forwarded message - --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
Am Mi, den 01.12.2004 schrieb Adam Jackson um 5:27: On Monday 29 November 2004 17:03, Felix Kühling wrote: There is no dri.freedesktop.org yet. I think there is no need for a redirect. The current place is already different from where it was before the break-in (used to be in ~dri/snapshots now it's in dri/snapshots). If you could setup a dri.freedesktop.org that would be great. Maybe we could move our Wiki from sourceforge to the new location. Ajax, are you reading this? What do you think about upgrading to a newer MoinMoin version with ACLs while we're at it. I wasn't reading, sorry, I was blissfully afk over the holiday. The moinmoin version on fd.o is a good one, so we should be able to just copy our old wiki over. I'll see if I can't hit this before I skip town again. What about José's modifications? How important are they and how difficult would it be to port them to the new version? - ajax -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
On Wednesday 01 December 2004 07:11, Felix Kühling wrote: Am Mi, den 01.12.2004 schrieb Adam Jackson um 5:27: I wasn't reading, sorry, I was blissfully afk over the holiday. The moinmoin version on fd.o is a good one, so we should be able to just copy our old wiki over. I'll see if I can't hit this before I skip town again. What about José's modifications? How important are they and how difficult would it be to port them to the new version? I don't know what his mods were, but I would guess not very. - ajax pgppZ3yTy2NxD.pgp Description: PGP signature
Re: DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
On Monday 29 November 2004 17:03, Felix Kühling wrote: There is no dri.freedesktop.org yet. I think there is no need for a redirect. The current place is already different from where it was before the break-in (used to be in ~dri/snapshots now it's in dri/snapshots). If you could setup a dri.freedesktop.org that would be great. Maybe we could move our Wiki from sourceforge to the new location. Ajax, are you reading this? What do you think about upgrading to a newer MoinMoin version with ACLs while we're at it. I wasn't reading, sorry, I was blissfully afk over the holiday. The moinmoin version on fd.o is a good one, so we should be able to just copy our old wiki over. I'll see if I can't hit this before I skip town again. - ajax pgpXqAM4tjNd6.pgp Description: PGP signature
DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
Am Sa, den 27.11.2004 schrieb Daniel Stone um 12:28: On Fri, 2004-11-26 at 15:46 +0100, Felix Kühling wrote: I just found http://www.freedesktop.org/dri/snapshots/. Now I wonder where I find this in the freedesktop.org filesystem. Is it /srv or /home/srv? Ah, I just saw it's the same thing with a bind mount from /home/srv to /srv. So I guess /srv is the path to use in scripts even it is ever moved to another file system. I'm going to set up a snapshot cron job in my freedesktop account that builds snapshots in my home dir and uploads them to /srv/www.freedesktop.org/dri/snapshots/. No. This should be under /srv/dri.freedesktop.org/snapshots, not www.freedesktop.org. If it is under www.freedesktop.org, I'll gladly set up a redirect for you. There is no dri.freedesktop.org yet. I think there is no need for a redirect. The current place is already different from where it was before the break-in (used to be in ~dri/snapshots now it's in dri/snapshots). If you could setup a dri.freedesktop.org that would be great. Maybe we could move our Wiki from sourceforge to the new location. Ajax, are you reading this? What do you think about upgrading to a newer MoinMoin version with ACLs while we're at it. On a related note, is it safe to put up the old snapshots? There is no guarantee of their integrity unless they come from a backup made before the break-in. Probably not. Only reason we put up the old CVS was that I took a snapshot of the entire CVS repository as of 20041015 and had it on a couple of known-good machines. I removed the snapshots from the public place. They're still in /home/compromised/projects/dri/public_html/snapshots though. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
Around 22 o'clock on Nov 29, Daniel Stone wrote: I don't know who put it in /dri/snapshots, but it absolutely should not be there. That would be me :-) I was trying to figure out how this stuff should work in the new regime and trying to get wiki links fixed up. If virtual hosts are the way to go, we can do that. Fortunately, virtual hosts are also wicked easy to configure (yay '*') -keith pgpZNGLdQeKiy.pgp Description: PGP signature
Re: DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
On Mon, 29 Nov 2004 23:03:35 +0100 Felix Kühling [EMAIL PROTECTED] wrote: I removed the snapshots from the public place. They're still in /home/compromised/projects/dri/public_html/snapshots though. Regards, Felix Hello, I'm just a user... But I need the snapshots between 06 September 2004 and 24 October 2004 to debug something. I'm willing to take any risk involved with using a rooted snapshot, but I need to know what set of changes broke my R200 with my app. Can you put the snapshots in a place I can access them ? Thanks François Cami --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
On Mon, 2004-11-29 at 23:03 +0100, Felix Khling wrote: Am Sa, den 27.11.2004 schrieb Daniel Stone um 12:28: No. This should be under /srv/dri.freedesktop.org/snapshots, not www.freedesktop.org. If it is under www.freedesktop.org, I'll gladly set up a redirect for you. There is no dri.freedesktop.org yet. I think there is no need for a redirect. The current place is already different from where it was before the break-in (used to be in ~dri/snapshots now it's in dri/snapshots). If you could setup a dri.freedesktop.org that would be great. Maybe we could move our Wiki from sourceforge to the new location. Ajax, are you reading this? What do you think about upgrading to a newer MoinMoin version with ACLs while we're at it. I don't know who put it in /dri/snapshots, but it absolutely should not be there. Projects have their own space under projectname.freedesktop.org if they want to use it, but the fd.o namespace should not be polluted further. That being said, I am of course happy to set up a redirect rule. Probably not. Only reason we put up the old CVS was that I took a snapshot of the entire CVS repository as of 20041015 and had it on a couple of known-good machines. I removed the snapshots from the public place. They're still in /home/compromised/projects/dri/public_html/snapshots though. Right, but if you take stuff from there, you'll get exactly what you deserve. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] snapshots status
On Fri, 2004-11-26 at 15:46 +0100, Felix Khling wrote: I just found http://www.freedesktop.org/dri/snapshots/. Now I wonder where I find this in the freedesktop.org filesystem. Is it /srv or /home/srv? Ah, I just saw it's the same thing with a bind mount from /home/srv to /srv. So I guess /srv is the path to use in scripts even it is ever moved to another file system. I'm going to set up a snapshot cron job in my freedesktop account that builds snapshots in my home dir and uploads them to /srv/www.freedesktop.org/dri/snapshots/. No. This should be under /srv/dri.freedesktop.org/snapshots, not www.freedesktop.org. If it is under www.freedesktop.org, I'll gladly set up a redirect for you. On a related note, is it safe to put up the old snapshots? There is no guarantee of their integrity unless they come from a backup made before the break-in. Probably not. Only reason we put up the old CVS was that I took a snapshot of the entire CVS repository as of 20041015 and had it on a couple of known-good machines. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] snapshots status
I just found http://www.freedesktop.org/dri/snapshots/. Now I wonder where I find this in the freedesktop.org filesystem. Is it /srv or /home/srv? Ah, I just saw it's the same thing with a bind mount from /home/srv to /srv. So I guess /srv is the path to use in scripts even it is ever moved to another file system. I'm going to set up a snapshot cron job in my freedesktop account that builds snapshots in my home dir and uploads them to /srv/www.freedesktop.org/dri/snapshots/. On a related note, is it safe to put up the old snapshots? There is no guarantee of their integrity unless they come from a backup made before the break-in. Regards, Felix Am Di, den 23.11.2004 schrieb Job Bob um 18:54: Hello. I want to get the latest dri snapshots from http://dri.freedesktop.org/~dri/snapshots, but that directory doesn't exist anymore. Is this due to the recent rebuild? If so, when will the snapshots be back up? -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status of DRM_MGA on x86_64
Thomas Zehetbauer wrote: Hi again, I have now changed Kconfig and successfully compiled, loaded and used DRI with a Matrox Millenium G550 on a dual Opteron system. I guess this is a pretty good test and I wonder if the problem has already been fixed or if it was limited to specific hard- or software. The problem, which exists with most (all?) DRM drivers, is that data types are used in the kernel/user interface that have different sizes on LP32 and LP64. If your kernel is 64-bit, you will have problems with 32-bit applications. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: status of DRM_MGA on x86_64
On Fre, 2004-10-29 at 12:47 -0700, Ian Romanick wrote: The problem, which exists with most (all?) DRM drivers, is that data types are used in the kernel/user interface that have different sizes on LP32 and LP64. If your kernel is 64-bit, you will have problems with 32-bit applications. Then either all or no DRM drivers should be enabled on x86_64, the DRM_TDFX, DRM_R128, DRM_RADEON and DRM_SIS are not currently disabled. I vote for enabling all drivers that work with 64-bit applications. I wonder if this should be the first and only place where different kernel/userland bitness causes problems. How has this been solved elsewhere? Tom -- T h o m a s Z e h e t b a u e r ( TZ251 ) PGP encrypted mail preferred - KeyID 96FFCB89 finger [EMAIL PROTECTED] for key Chemists don't die, they just stop to react. signature.asc Description: This is a digitally signed message part
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Fri, Oct 15, 2004 at 11:40:30AM -0400, Jon Smirl wrote: On Fri, 15 Oct 2004 15:19:41 +0100, José Fonseca [EMAIL PROTECTED] wrote: It doesn't say nothing and I found (partially) why: the dynamic lynking is failing, so the call to drm_init(pci_driver, pciidlist, driver) never reaches a single line of code there (no debug message, *nothing*). Could it be symbol versioning? I've diffed my two machines kernel config files and symbol versioning was one of the suspicious differences indeed, but I only managed to get everything working as expected after disabling some of those kernel hacking options too. Things behave weirdly if you have an old drm module loaded and load the new ones too. You should at least get a sign on: [drm] Initialized drm 1.0.0 20040925 Yes, this message always appeared when loading drm.ko. That the very first thing the drm module does. If you sync from CVS you need to use... insmod ./drm.ko drm_debug=1 Thanks for your help. This issue is finally closed. Regards, José Fonseca --- 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: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Mon, Oct 11, 2004 at 10:52:40AM -0400, Jon Smirl wrote: What does dmesg say? There should be some debugging data in the log. drm loads right? which personality is failing? It doesn't say nothing and I found (partially) why: the dynamic lynking is failing, so the call to drm_init(pci_driver, pciidlist, driver) never reaches a single line of code there (no debug message, *nothing*). I still don't know how this can be (the kernel configuration, or software setup, maybe), but I'm more inclined toward a problem on my end, rather than in *-core code. I'll still try sorting this out, so that I can move on to more interesting things. José Fonseca --- 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
