Re: [PATCH] drm & i915 vblank fixes
On Sun, 2008-07-20 at 12:46 +0200, Michel Dänzer wrote: > On Sat, 2008-07-19 at 12:54 -0400, Robert Noland wrote: > > > > One other issue that I spotted while testing is that we initialize > > vblank_disable_allowed to 0. The only place that it ever becomes true > > is in post modeset. So, for me... vblanks were never getting disabled. > > Yes, that's the intention behind vblank_disable_allowed. :) It's to > prevent the interrupt from getting disabled until the display driver > calls the modeset ioctl, to prevent problems caused by the hardware > frame counter resetting to 0 with 'old' display drivers (meaning ones > that don't know to call the modeset ioctl). That said, I encountered this with radeon as well. Turns out the initial modeset is done before the DRM IRQ handler is initialized, so the modeset ioctl just no-ops. I added two ioctl calls after the drmCtlInstHandler() call to make sure the vblank interrupts can get disabled right after startup, maybe xf86-video-intel needs something similar. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Dösinger wrote: |> So ALL Radeons can do decompression. Right now we have a system where |> we |> only upload S3TC textures if they were precompressed (NWN, UT2K4, etc.) |> and we have to force the extension on in order to do it. | This may be slightly off topic, but I am wondering if there's any way to | detect the ability to upload precompressed textures when | GL_EXT_texture_compression_s3tc is not available(aka the user hasn't forced | it). Wine and CrossOver users are regularly complaining that their games do | not work due to the lack of S3TC, but all Wine needs for D3D is the ability | to load precompressed textures(*). So I'd be perfectly happy with getting | just this feature, if the user just didn't have to do anything manually. There are two problems for Mesa. 1. Compressing raw textures to the S3TC formats. As was mentioned later in the thread, there is an extension that exposes DXT1 without this requirement. 2. Decompressing textures for software fallbacks. As far as I'm aware, all of the drivers still have some software fallbacks, so this support is still required. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiFA9MACgkQX1gOwKyEAw/k/ACghQypfRsexjF8wqa5UxoyYQ9p 1QEAoJILJ536IDND19uARMZO91w8dtZ4 =1wRL -END PGP SIGNATURE- - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10985] backlight doesn't come on after resume with i915 video
http://bugzilla.kernel.org/show_bug.cgi?id=10985 --- Comment #37 from [EMAIL PROTECTED] 2008-07-21 14:41 --- And I don't suppose the register diff changes either? -- 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. - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger schrieb: >> If you only use DXT1 there's EXT_texture_compression_dxt1. It offers >> support for using DXT1 precompressed textures. However AFAIK it'S >> currently not supported in the free drivers (even if >> GL_EXT_texture_compression_s3tc is avialable). > > Yes, that's true. Also, it wouldn't work (if no software decompression > is available) in a software fallback (which generally I guess shouldn't > be much of a problem). Can't we just render a quad, with filtering set to nearest and readback to decompress and use the decompressed texture for the software fallback? Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiFAdwACgkQbtUV+xsoLpp1VwCgpffxq6x7YOc53fIztLT7j4DM cgIAoJ9b+YbU7G1jc6q2dIEBCcj1k40w =0kIp -END PGP SIGNATURE- - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
On 21.07.2008 23:10, Corbin Simpson wrote: > Philipp Klaus Krause wrote: >> Stefan Dösinger schrieb: >>> This may be slightly off topic, but I am wondering if there's any way to >>> detect the ability to upload precompressed textures when >>> GL_EXT_texture_compression_s3tc is not available(aka the user hasn't forced >>> it). Wine and CrossOver users are regularly complaining that their games do >>> not work due to the lack of S3TC, but all Wine needs for D3D is the ability >>> to load precompressed textures(*). So I'd be perfectly happy with getting >>> just this feature, if the user just didn't have to do anything manually. >>> I think writing an extension spec is outside of the scope, but is there >>> something else, like setting an environment variable, or just trying to call >>> glCompressedTexImage even thought the extension isn't advertised? >>> Thanks, >>> Stefan >>> (*) D3D has a feature to compress textures, but it is independent of the >>> hardware's features. >> If you only use DXT1 there's EXT_texture_compression_dxt1. It offers >> support for using DXT1 precompressed textures. However AFAIK it'S >> currently not supported in the free drivers (even if >> GL_EXT_texture_compression_s3tc is avialable). > > Ooh, seems nice, even though it's OGLES. I'm putting that on my todo > list for Radeons. There wouldn't be any code necessary for the radeon driver (other than announcing the extension), this would all be core mesa. Roland - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
On 21.07.2008 22:09, Philipp Klaus Krause wrote: > Stefan Dösinger schrieb: >> This may be slightly off topic, but I am wondering if there's any way to >> detect the ability to upload precompressed textures when >> GL_EXT_texture_compression_s3tc is not available(aka the user hasn't forced >> it). Wine and CrossOver users are regularly complaining that their games do >> not work due to the lack of S3TC, but all Wine needs for D3D is the ability >> to load precompressed textures(*). So I'd be perfectly happy with getting >> just this feature, if the user just didn't have to do anything manually. > >> I think writing an extension spec is outside of the scope, but is there >> something else, like setting an environment variable, or just trying to call >> glCompressedTexImage even thought the extension isn't advertised? > >> Thanks, >> Stefan > >> (*) D3D has a feature to compress textures, but it is independent of the >> hardware's features. > > If you only use DXT1 there's EXT_texture_compression_dxt1. It offers > support for using DXT1 precompressed textures. However AFAIK it'S > currently not supported in the free drivers (even if > GL_EXT_texture_compression_s3tc is avialable). Yes, that's true. Also, it wouldn't work (if no software decompression is available) in a software fallback (which generally I guess shouldn't be much of a problem). Also note that setting an environment variable will do the trick already, since you can override all driconf options with environment vars (force_s3tc_enable=true in this case). Roland - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp Klaus Krause wrote: > Stefan Dösinger schrieb: >> This may be slightly off topic, but I am wondering if there's any way to >> detect the ability to upload precompressed textures when >> GL_EXT_texture_compression_s3tc is not available(aka the user hasn't forced >> it). Wine and CrossOver users are regularly complaining that their games do >> not work due to the lack of S3TC, but all Wine needs for D3D is the ability >> to load precompressed textures(*). So I'd be perfectly happy with getting >> just this feature, if the user just didn't have to do anything manually. > >> I think writing an extension spec is outside of the scope, but is there >> something else, like setting an environment variable, or just trying to call >> glCompressedTexImage even thought the extension isn't advertised? > >> Thanks, >> Stefan > >> (*) D3D has a feature to compress textures, but it is independent of the >> hardware's features. > > If you only use DXT1 there's EXT_texture_compression_dxt1. It offers > support for using DXT1 precompressed textures. However AFAIK it'S > currently not supported in the free drivers (even if > GL_EXT_texture_compression_s3tc is avialable). Ooh, seems nice, even though it's OGLES. I'm putting that on my todo list for Radeons. ~ C. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiE+1wACgkQeCCY8PC5utDRAwCfX3x3skZxOVvuQt50ICLQ3y2t PSkAn1EasZ9K4vLyq59ecvDjXyMwLFfX =uMT7 -END PGP SIGNATURE- - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10985] backlight doesn't come on after resume with i915 video
http://bugzilla.kernel.org/show_bug.cgi?id=10985 --- Comment #36 from [EMAIL PROTECTED] 2008-07-21 13:59 --- Hello; tried that patch against refs/heads/master = b5cddbcc1536 ; I'm afraid it did not fix it. -- 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. - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Dösinger schrieb: > This may be slightly off topic, but I am wondering if there's any way to > detect the ability to upload precompressed textures when > GL_EXT_texture_compression_s3tc is not available(aka the user hasn't forced > it). Wine and CrossOver users are regularly complaining that their games do > not work due to the lack of S3TC, but all Wine needs for D3D is the ability > to load precompressed textures(*). So I'd be perfectly happy with getting > just this feature, if the user just didn't have to do anything manually. > > I think writing an extension spec is outside of the scope, but is there > something else, like setting an environment variable, or just trying to call > glCompressedTexImage even thought the extension isn't advertised? > > Thanks, > Stefan > > (*) D3D has a feature to compress textures, but it is independent of the > hardware's features. If you only use DXT1 there's EXT_texture_compression_dxt1. It offers support for using DXT1 precompressed textures. However AFAIK it'S currently not supported in the free drivers (even if GL_EXT_texture_compression_s3tc is avialable). Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiE7OQACgkQbtUV+xsoLprVfACeM/OLWBBziwcJuFfATXbfOBch M84AoIqj96h0eZ0zPrrhv6X1lLuTPQ1K =41u8 -END PGP SIGNATURE- - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10985] backlight doesn't come on after resume with i915 video
http://bugzilla.kernel.org/show_bug.cgi?id=10985 --- Comment #35 from [EMAIL PROTECTED] 2008-07-21 13:01 --- Created an attachment (id=16927) --> (http://bugzilla.kernel.org/attachment.cgi?id=16927&action=view) disable panel & restore all panel state first this one tries to disable the panel first thing, since that should unlock some of the regs that we may be failing to restore. -- 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. - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: Texture compression patents
> So ALL Radeons can do decompression. Right now we have a system where > we > only upload S3TC textures if they were precompressed (NWN, UT2K4, etc.) > and we have to force the extension on in order to do it. This may be slightly off topic, but I am wondering if there's any way to detect the ability to upload precompressed textures when GL_EXT_texture_compression_s3tc is not available(aka the user hasn't forced it). Wine and CrossOver users are regularly complaining that their games do not work due to the lack of S3TC, but all Wine needs for D3D is the ability to load precompressed textures(*). So I'd be perfectly happy with getting just this feature, if the user just didn't have to do anything manually. I think writing an extension spec is outside of the scope, but is there something else, like setting an environment variable, or just trying to call glCompressedTexImage even thought the extension isn't advertised? Thanks, Stefan (*) D3D has a feature to compress textures, but it is independent of the hardware's features. - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm & i915 vblank fixes
On Sunday, July 20, 2008 3:46 am Michel Dänzer wrote: > On Sat, 2008-07-19 at 12:54 -0400, Robert Noland wrote: > > One other issue that I spotted while testing is that we initialize > > vblank_disable_allowed to 0. The only place that it ever becomes true > > is in post modeset. So, for me... vblanks were never getting disabled. > > Yes, that's the intention behind vblank_disable_allowed. :) It's to > prevent the interrupt from getting disabled until the display driver > calls the modeset ioctl, to prevent problems caused by the hardware > frame counter resetting to 0 with 'old' display drivers (meaning ones > that don't know to call the modeset ioctl). > > > I'm still (or again) sometimes getting the error about get_vblank_count > > being called on disabled pipe that I need to try and chase down. > > I think that's because the 3D driver is trying to sync to a pipe that > the display driver 'disabled'. Yeah, and it's a common error. Maybe we should make the message into a DRM_DEBUG instead, or make it a little less scary. 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] DRM developer guide
On Sunday, July 20, 2008 3:10 am Maarten Maathuis wrote: > Has it been considered to put this up somewhere for autogeneration? > > I'm not very familiar with these documentation schemes, but i imagine > it's a matter of putting appropriately styled comments in code and > they'll appear? > > It would be a shame if this got lost in the drift of time. Some of it can definitely be autogenerated, for instance all the API & structure documentation. However the high level documentation is really separate. I'm not sure how easy it would be to include in the sources; it would probably clutter things up quite a bit... 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger wrote: > On 20.07.2008 19:32, Corbin Simpson wrote: >> Howdy. I was just going through the r3xx/r5xx bugs, and I noticed that >> lots of problems are related to certain texture compression features >> being dependent on out-of-tree code. I also noticed that, at least on >> R400+ Radeons, we actually have hardware support for such compression, >> and I thought that was the case on certain nVidia chipsets, too. >> >> My question is, does anybody know the status on S3TC/DXTC/etc., and if >> it's still owned by S3/VIA, and if they might be interested in opening it? >> >> ...Oh, I guess that's three questions. :3 >> >> ~ C. > > What do you mean with "have hardware support for such compression"? Even > very old r100 (and chips from other IHVs) have support for it. But they > only have hardware support for decompression, not compression which is > what you'd need too for OpenGL conformance. I'd be surprised to hear > R400 can do compression. I know it's possible to do online-compression > on new hardware with shaders, but I think it might require more like > R600 class hardware. And it probably wouldn't change anything, since > you'd just implement the same algorithm on the gpu instead of the cpu > (it still would be software-based implementation). Okay, nevermind, I did some more reading. So ALL Radeons can do decompression. Right now we have a system where we only upload S3TC textures if they were precompressed (NWN, UT2K4, etc.) and we have to force the extension on in order to do it. This is NOT ideal. I couldn't help but notice that VIA has been open-sourcing stuff left 'n' right, and wondered if maaaybe they might be interested in loosening their grip on that particular patent since it's already implemented in *all modern graphics hardware* already. Or maybe this'll just be another LinDVD kind of thing... ~ C. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiEzKgACgkQeCCY8PC5utA4RwCfVu8j7h6/7dn9SjAxVyHEg1dH hysAoIy8YhRB0WpPQgz4FTOpHwN411+8 =bakE -END PGP SIGNATURE- - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
On 20.07.2008 19:32, Corbin Simpson wrote: > Howdy. I was just going through the r3xx/r5xx bugs, and I noticed that > lots of problems are related to certain texture compression features > being dependent on out-of-tree code. I also noticed that, at least on > R400+ Radeons, we actually have hardware support for such compression, > and I thought that was the case on certain nVidia chipsets, too. > > My question is, does anybody know the status on S3TC/DXTC/etc., and if > it's still owned by S3/VIA, and if they might be interested in opening it? > > ...Oh, I guess that's three questions. :3 > > ~ C. What do you mean with "have hardware support for such compression"? Even very old r100 (and chips from other IHVs) have support for it. But they only have hardware support for decompression, not compression which is what you'd need too for OpenGL conformance. I'd be surprised to hear R400 can do compression. I know it's possible to do online-compression on new hardware with shaders, but I think it might require more like R600 class hardware. And it probably wouldn't change anything, since you'd just implement the same algorithm on the gpu instead of the cpu (it still would be software-based implementation). Roland - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16786] mesa-7.1: googleearth, sauerbraten not working anymore
http://bugs.freedesktop.org/show_bug.cgi?id=16786 Roland Scheidegger <[EMAIL PROTECTED]> changed: What|Removed |Added Component|Drivers/DRI/Radeon |Drivers/DRI/r300 -- 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
true boolean in drm_agpsupport.c
Hi folks,
since my compiler always complains about that during (aborted)
compilation of the kernel modules I decided to send that patch to the ML.
Can we safely replace TRUE/FALSE by the boolean values true/false?
Cheers, Johannes
Signed-off-by: Johannes Engel <[EMAIL PROTECTED]>
Replace old TRUE/FALSE by true boolean true/false
linux-core/drm_agpsupport.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/linux-core/drm_agpsupport.c b/linux-core/drm_agpsupport.c
index d6594b8..3cc94ff 100644
--- a/linux-core/drm_agpsupport.c
+++ b/linux-core/drm_agpsupport.c
@@ -517,7 +517,7 @@ drm_agp_bind_pages(struct drm_device *dev,
mem->memory[i] = phys_to_gart(page_to_phys(pages[i]));
mem->page_count = num_pages;
- mem->is_flushed = TRUE;
+ mem->is_flushed = true;
ret = drm_agp_bind_memory(mem, gtt_offset / PAGE_SIZE);
if (ret != 0) {
DRM_ERROR("Failed to bind AGP memory: %d\n", ret);
@@ -597,7 +597,7 @@ static int drm_agp_bind_ttm(struct drm_ttm_backend *backend,
int snooped = (bo_mem->flags & DRM_BO_FLAG_CACHED) && !(bo_mem->flags & DRM_BO_FLAG_CACHED_MAPPED);
DRM_DEBUG("drm_agp_bind_ttm\n");
- mem->is_flushed = TRUE;
+ mem->is_flushed = true;
mem->type = AGP_USER_MEMORY;
/* CACHED MAPPED implies not snooped memory */
if (snooped)
@@ -696,7 +696,7 @@ struct drm_ttm_backend *drm_agp_init_ttm(struct drm_device *dev)
agp_be->mem = NULL;
agp_be->bridge = dev->agp->bridge;
- agp_be->populated = FALSE;
+ agp_be->populated = false;
agp_be->backend.func = &agp_ttm_backend;
agp_be->backend.dev = dev;
-
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=100&url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/1] DRM: don't enable irqs in locking
drm_lock_take(); and drm_lock_free(); are called from
drm_locked_tasklet_func(); which disables interrupts when grabbing its
spinlock.
Don't allow these locking functions to re-enable interrupts when
the tasklet expects them disabled. I.e. use spin_lock_irqsave instead of
spin_lock_bh (with their unlock opposites).
We will get such a warnings otherwise:
[ cut here ]
WARNING: at kernel/softirq.c:136 local_bh_enable_ip+0x8b/0xb0()
Modules linked in: arc4 ecb crypto_blkcipher cryptomgr crypto_algapi ath5k
usbhid mac80211 ohci1394 hid led_class floppy cfg80211 ff_memless ieee1394
rtc_cmos evdev [last unloaded: freq_table]
Pid: 0, comm: swapper Not tainted 2.6.26-rc8-mm1_64 #427
Call Trace:
[] warn_on_slowpath+0x5f/0x90
[...]
[] local_bh_enable_ip+0x8b/0xb0
[] _spin_unlock_bh+0xf/0x20
[] drm_lock_take+0x81/0xe0
[] drm_locked_tasklet_func+0x4b/0xb0
[] tasklet_hi_action+0x69/0xf0
[] __do_softirq+0x84/0xf0
[stack snipped]
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Cc: David Airlie <[EMAIL PROTECTED]>
---
drivers/gpu/drm/drm_lock.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 0998723..79943e4 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -196,10 +196,11 @@ int drm_unlock(struct drm_device *dev, void *data, struct
drm_file *file_priv)
int drm_lock_take(struct drm_lock_data *lock_data,
unsigned int context)
{
+ unsigned long flags;
unsigned int old, new, prev;
volatile unsigned int *lock = &lock_data->hw_lock->lock;
- spin_lock_bh(&lock_data->spinlock);
+ spin_lock_irqsave(&lock_data->spinlock, flags);
do {
old = *lock;
if (old & _DRM_LOCK_HELD)
@@ -211,7 +212,7 @@ int drm_lock_take(struct drm_lock_data *lock_data,
}
prev = cmpxchg(lock, old, new);
} while (prev != old);
- spin_unlock_bh(&lock_data->spinlock);
+ spin_unlock_irqrestore(&lock_data->spinlock, flags);
if (_DRM_LOCKING_CONTEXT(old) == context) {
if (old & _DRM_LOCK_HELD) {
@@ -270,17 +271,18 @@ static int drm_lock_transfer(struct drm_lock_data
*lock_data,
*/
int drm_lock_free(struct drm_lock_data *lock_data, unsigned int context)
{
+ unsigned long flags;
unsigned int old, new, prev;
volatile unsigned int *lock = &lock_data->hw_lock->lock;
- spin_lock_bh(&lock_data->spinlock);
+ spin_lock_irqsave(&lock_data->spinlock, flags);
if (lock_data->kernel_waiters != 0) {
drm_lock_transfer(lock_data, 0);
lock_data->idle_has_lock = 1;
- spin_unlock_bh(&lock_data->spinlock);
+ spin_unlock_irqrestore(&lock_data->spinlock, flags);
return 1;
}
- spin_unlock_bh(&lock_data->spinlock);
+ spin_unlock_irqrestore(&lock_data->spinlock, flags);
do {
old = *lock;
--
1.5.6.2
-
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=100&url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16786] New: mesa-7.1: googleearth, sauerbraten not working anymore
http://bugs.freedesktop.org/show_bug.cgi?id=16786 Summary: mesa-7.1: googleearth, sauerbraten not working anymore Product: Mesa Version: 7.1 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] I was updating my system (with the steps explained here: http://dberkholz.wordpress.com/2008/07/01/xorg-74-prereleases-ready-to-test-in-gentoo/ Now I have the following problems: google earth (native) hangs on splash screen - the trick with the libGL.so.1 will not work anymore google earth (via wine) there is no earth sauerbraten after initialisation I have a black screen and to kill the game http://dberkholz.wordpress.com/2008/07/01/xorg-74-prereleases-ready-to-test-in-gentoo/#comment-137 I hope the bug report is at the right place. lspci: = 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] = glxinfo: = name of display: :1.0 display: :1 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: DRI R300 Project OpenGL renderer string: Mesa DRI R300 20060815 AGP 8x TCL OpenGL version string: 1.3 Mesa 7.1 rc3 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_shadow, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_MESAX_texture_float, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SUN_multi_draw_arrays visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b
testing i915_tex , from mesa_7_0_branch
cd ../Mesa-7.0.4/ git pull origin i915tex_branch git pull origin mesa_7_0_branch git log commit 45eb62ad6159408807ff86d24dd972e0f39cefb8 Merge: 97eb335... 7734956... Author: root <[EMAIL PROTECTED]> Date: Mon Jul 21 09:50:15 2008 +0100 Merge branch 'i915tex_branch' of git://anongit.freedesktop.org/git/mesa/mesa into HEAD Cool, Git says that I merged i915tex into HEAD , But this i915tex, needs drm HEAD , (which is with TTM stuff) or drm-2.3.1 is enough ? TIA, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature - 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=100&url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
