[RFC] drm: allow unlocked ioctls in drivers
I just tried to find out what it would take to get the BKL /mostly/
out of drm. The approach I tried was to add another flag to the
ioctl list for commands that do not need the big kernel lock.
I blindly applied this flag to all the most commonly used ioctl
commands without checking if they actually rely on the lock.
This cuts down the overall BKL usage on my system by about 90%.
Based on the previous patch to turn drm_ioctl itself into an
unlocked call.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
The machine still crashes because of another problem I'm trying to nail
down (coincidentally in the same driver), so I don't even have a way of
testing if this otherwise works, but the crashes did not seem to get
more frequent either...
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -502,9 +502,13 @@ long drm_ioctl(struct file *filp,
goto err_i1;
}
}
- lock_kernel();
- retcode = func(dev, kdata, file_priv);
- unlock_kernel();
+ if (ioctl-flags DRM_UNLOCKED)
+ retcode = func(dev, kdata, file_priv);
+ else {
+ lock_kernel();
+ retcode = func(dev, kdata, file_priv);
+ unlock_kernel();
+ }
if (cmd IOC_OUT) {
if (copy_to_user((void __user *)arg, kdata,
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 701bfea..67d78d6 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1651,20 +1651,20 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF(DRM_I915_VBLANK_SWAP, i915_vblank_swap, DRM_AUTH),
DRM_IOCTL_DEF(DRM_I915_HWS_ADDR, i915_set_status_page,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_I915_GEM_INIT, i915_gem_init_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_I915_GEM_EXECBUFFER, i915_gem_execbuffer, DRM_AUTH),
+ DRM_IOCTL_DEF(DRM_I915_GEM_EXECBUFFER, i915_gem_execbuffer,
DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_I915_GEM_PIN, i915_gem_pin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_I915_GEM_UNPIN, i915_gem_unpin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_I915_GEM_BUSY, i915_gem_busy_ioctl, DRM_AUTH),
- DRM_IOCTL_DEF(DRM_I915_GEM_THROTTLE, i915_gem_throttle_ioctl, DRM_AUTH),
+ DRM_IOCTL_DEF(DRM_I915_GEM_BUSY, i915_gem_busy_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_I915_GEM_ENTERVT, i915_gem_entervt_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_I915_GEM_CREATE, i915_gem_create_ioctl, 0),
- DRM_IOCTL_DEF(DRM_I915_GEM_PREAD, i915_gem_pread_ioctl, 0),
- DRM_IOCTL_DEF(DRM_I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 0),
- DRM_IOCTL_DEF(DRM_I915_GEM_MMAP, i915_gem_mmap_ioctl, 0),
- DRM_IOCTL_DEF(DRM_I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 0),
- DRM_IOCTL_DEF(DRM_I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 0),
- DRM_IOCTL_DEF(DRM_I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 0),
+ DRM_IOCTL_DEF(DRM_I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl,
DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl,
DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl,
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_I915_GEM_SET_TILING, i915_gem_set_tiling, 0),
DRM_IOCTL_DEF(DRM_I915_GEM_GET_TILING, i915_gem_get_tiling, 0),
DRM_IOCTL_DEF(DRM_I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
0),
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 5b1bbe0..71dafb6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -296,6 +296,7 @@ typedef int drm_ioctl_compat_t(struct file *filp, unsigned
int cmd,
#defineDRM_MASTER 0x2
#define DRM_ROOT_ONLY 0x4
#define DRM_CONTROL_ALLOW 0x8
+#define DRM_UNLOCKED 0x10
struct drm_ioctl_desc {
unsigned int cmd;
--
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
--
Re: [PATCH] drm/radeon/kms: add dynamic engine reclocking (V6)
v6 runs fine on rv515. Thanks Rafal. --- Speedup in 3D: Running Anholt's openarena benchmark demo --- $ openarena +exec anholt 21 | egrep -e '[0-9]+ frames' NEW: 840 frames 10.2 seconds 82.1 fps 4.0/12.2/56.0/5.4 ms OLD: 840 frames 37.4 seconds 22.4 fps 15.0/44.6/97.0/13.4 ms Even playing a youtube music-video in firefox parallelly reduces fps down to 63. System description: [1] kernel: upstream 2.6.32-git13 (incl. drm-linus) +0001-drm-radeon-kms-add-dynamic-engine-reclocking-V6.patch +0001-drm-radeon-kms-prevent-parallel-AtomBIOS-calls.patch [2] ddx: xf86-video-ati 6.12.99 (git20091210.f198590) [3] libdrm 2.4.16 [4] mesa-7.8: Using r300g dri/statetracker commit 09cef45393c14d2b02529cb3cbea194bdfc06bf3 r600 : clean a bit to prepare to enable gl2. [5] xorg-server 1.7.3.901 [6] KMS enabled (modeset=1) and DynPM enabled (dynpm=1) Thanks to all contributor to Gallium3D Radeon (r300g). - Sedat - 2009/12/17 Rafał Miłecki zaj...@gmail.com: V2: reorganize functions, fix modesetting calls V3: rebase patch, use radeon's workqueue V4: enable on tested chipsets only, request VBLANK IRQs V5: enable PM on older hardware (IRQs, mode_fixup, dpms) V6: use separate dynpm module parameter Tested on my M82==RV620 and my new M96==RV730. Also tested on RV515 by Sedat where already posted patch for AtomBIOS's mutex was needed. -- Rafał -- 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
[Bug 25679] R600: Winding is inverted when rendering to FBO
http://bugs.freedesktop.org/show_bug.cgi?id=25679 --- Comment #5 from Andy Furniss li...@andyfurniss.entadsl.com 2009-12-17 03:51:43 PST --- (In reply to comment #4) Pushed: 20ee275974a58cd221031d522ad58a9548af2a31 Doesn't seem to fix progs/demos/fbotexture for me on RV670 AGP kms. -- 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 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: [RFC] radeon bo/cs API cleanup
On Thu, 2009-12-17 at 14:34 +1000, Dave Airlie wrote: Hi, so Michel pointed out that the libdrm_radeon API was pretty unmaintainble. Reasons: 1. inlines in headers mean API/ABI is fixed completely. 2. All of structure internals for bo/cs are exposed. 3. RADEON_BO_TRACK changed the library API when on/off. So I a) removed bo tracking b) split the cs/bo structs into public/private parts and minimised the members, the cs_int/bo_int need to reflect the public bits. c) left some members intact for fast paths for functions that need it (write_dword) 3 patches attached, libdrm/ddx/mesa (no r300g bits yet) to clean the API of all of this. I'd like to then declare this as the stable API going forward. Thanks Dave, these look good. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- 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: [PATCH] drm/radeon/kms: enable memory clock reading on legacy
W dniu 17 grudnia 2009 05:56 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/16 Rafał Miłecki zaj...@gmail.com: Tested by bjaglin on IRC on RV250. Probably shouldn't enable the mem clock stuff on IGP chips since they use system memory. Ups. I think it's general bug, not only introduced by proposed patch. For newer (not legacy) GPU we don't check for being IGP as well. Could you comment on attached solution, please? -- Rafał 0001-drm-radeon-kms-enable-memory-clock-reading-on-legacy.patch Description: Binary data -- 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
[Bug 25679] R600: Winding is inverted when rendering to FBO
http://bugs.freedesktop.org/show_bug.cgi?id=25679 --- Comment #6 from Alex Deucher ag...@yahoo.com 2009-12-17 07:52:29 PST --- (In reply to comment #5) (In reply to comment #4) Pushed: 20ee275974a58cd221031d522ad58a9548af2a31 Doesn't seem to fix progs/demos/fbotexture for me on RV670 AGP kms. I applied to to the 7.6 branch, so if you tried master or 7.7 branch, it's not there yet. -- 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 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
[Bug 25679] R600: Winding is inverted when rendering to FBO
http://bugs.freedesktop.org/show_bug.cgi?id=25679 --- Comment #7 from Andy Furniss li...@andyfurniss.entadsl.com 2009-12-17 08:05:32 PST --- (In reply to comment #6) I applied to to the 7.6 branch, so if you tried master or 7.7 branch, it's not there yet. Ahh, I am on master. I didn't realise that git show would show things from other branches. -- 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 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: [PATCH] drm/radeon/kms: enable memory clock reading on legacy
2009/12/17 Rafał Miłecki zaj...@gmail.com: W dniu 17 grudnia 2009 05:56 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/16 Rafał Miłecki zaj...@gmail.com: Tested by bjaglin on IRC on RV250. Probably shouldn't enable the mem clock stuff on IGP chips since they use system memory. Ups. I think it's general bug, not only introduced by proposed patch. For newer (not legacy) GPU we don't check for being IGP as well. Could you comment on attached solution, please? That should do the trick. Alex -- 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: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Wed, 16 Dec 2009 22:41:27 + Arnd Bergmann a...@arndb.de wrote: On Wednesday 16 December 2009 21:36:36 Arnd Bergmann wrote: On Wednesday 16 December 2009 21:30:05 Jesse Barnes wrote: But you're sure powersave=0 was solid? Hmm... It's hard to be sure when it sometimes takes a day before a broken version crashes. I can keep running this kernel with and without powersave=0 some more and tell you if it stays reproducible. Now it has crashed with i915.powersave=0 plus your patch as well (latest 2.6.32 git), indicating that there is something else wrong with the original 652c393a33 patch. It does very little else that should affect things. You're sure reverting the commit makes things ok? Other potential problems: - clock gating (the call to intel_init_clock_gating) - the actual mark_busy stuff itself (calls to intel_mark_busy) - intel_idle_update (but powersave=0 should prevent that) If you want to keep testing you could try removing those calls... -- Jesse Barnes, Intel Open Source Technology Center -- 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: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Thursday 17 December 2009, Jesse Barnes wrote: It does very little else that should affect things. You're sure reverting the commit makes things ok? No, not sure. But I've been running the kernel before that commit for days without ever seeing a crash. 2.6.31 (also without that commit but otherwise pretty similar) has been stable for weeks weeks on the same box. Once any given kernel version crashes, which can take up to a day while I'm waiting for the bug to show up, it will typically crash on that same kernel again within seconds after boot, just to annoy me and prevent me from using that kernel for other things. Other potential problems: - clock gating (the call to intel_init_clock_gating) - the actual mark_busy stuff itself (calls to intel_mark_busy) - intel_idle_update (but powersave=0 should prevent that) If you want to keep testing you could try removing those calls... Ok, I'll try that. The problem is keeping me from doing any useful upstream kernel work on my main machine, so I'm rather motivated ;-) Arnd -- 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
[mesa] Fixes after Merge branch 'glsl-pp-rework-2'
Here two patches fixing mesa GIT master after: commit e195eab9093d2a6cf55a42b2e7789c9a381b7782 Merge branch 'glsl-pp-rework-2' (Thanks to Ghworg on IRC) - Sedat - From d99b3f641500e9862ea6bae26d3524ac95c84488 Mon Sep 17 00:00:00 2001 From: Sedat Dilek sedat.di...@gmail.com Date: Thu, 17 Dec 2009 19:14:53 +0100 Subject: [PATCH] configure.ac: Add glsl to SRC_DIRS --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 25e4321..6fa0a60 100644 --- a/configure.ac +++ b/configure.ac @@ -413,7 +413,7 @@ esac dnl dnl Driver specific build directories dnl -SRC_DIRS=mesa glew +SRC_DIRS=glsl mesa glew GLU_DIRS=sgi WINDOW_SYSTEM= GALLIUM_DIRS=auxiliary drivers state_trackers -- 1.6.5.4 From 06411ca499507698b48e486aac3d344f3e47f21a Mon Sep 17 00:00:00 2001 From: Sedat Dilek sedat.di...@gmail.com Date: Thu, 17 Dec 2009 19:17:23 +0100 Subject: [PATCH] glsl/apps: Add dummy install target to fix 'make install' --- src/glsl/apps/Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/glsl/apps/Makefile b/src/glsl/apps/Makefile index c80fcb9..39a0df7 100644 --- a/src/glsl/apps/Makefile +++ b/src/glsl/apps/Makefile @@ -36,7 +36,8 @@ INCLUDES = -I. default: $(APPS) +install: + clean: -rm -f $(APPS) -rm -f *.o - -- 1.6.5.4 -- 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: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Thu, 17 Dec 2009 18:52:02 +0100
Arnd Bergmann a...@arndb.de wrote:
On Thursday 17 December 2009, Jesse Barnes wrote:
It does very little else that should affect things. You're sure
reverting the commit makes things ok?
No, not sure. But I've been running the kernel before that commit
for days without ever seeing a crash. 2.6.31 (also without that
commit but otherwise pretty similar) has been stable for weeks
weeks on the same box.
Once any given kernel version crashes, which can take up to
a day while I'm waiting for the bug to show up, it will typically
crash on that same kernel again within seconds after boot,
just to annoy me and prevent me from using that kernel for
other things.
Other potential problems:
- clock gating (the call to intel_init_clock_gating)
- the actual mark_busy stuff itself (calls to intel_mark_busy)
- intel_idle_update (but powersave=0 should prevent that)
If you want to keep testing you could try removing those calls...
Ok, I'll try that. The problem is keeping me from doing any useful
upstream kernel work on my main machine, so I'm rather motivated ;-)
Another patch to try...
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 279dc96..b8ca398 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3779,125 +3779,6 @@ static void intel_gpu_idle_timer(unsigned long arg)
queue_work(dev_priv-wq, dev_priv-idle_work);
}
-void intel_increase_renderclock(struct drm_device *dev, bool schedule)
-{
- drm_i915_private_t *dev_priv = dev-dev_private;
-
- if (IS_IRONLAKE(dev))
- return;
-
- if (!dev_priv-render_reclock_avail) {
- DRM_DEBUG_DRIVER(not reclocking render clock\n);
- return;
- }
-
- /* Restore render clock frequency to original value */
- if (IS_G4X(dev) || IS_I9XX(dev))
- pci_write_config_word(dev-pdev, GCFGC, dev_priv-orig_clock);
- else if (IS_I85X(dev))
- pci_write_config_word(dev-pdev, HPLLCC, dev_priv-orig_clock);
- DRM_DEBUG_DRIVER(increasing render clock frequency\n);
-
- /* Schedule downclock */
- if (schedule)
- mod_timer(dev_priv-idle_timer, jiffies +
- msecs_to_jiffies(GPU_IDLE_TIMEOUT));
-}
-
-void intel_decrease_renderclock(struct drm_device *dev)
-{
- drm_i915_private_t *dev_priv = dev-dev_private;
-
- if (IS_IRONLAKE(dev))
- return;
-
- if (!dev_priv-render_reclock_avail) {
- DRM_DEBUG_DRIVER(not reclocking render clock\n);
- return;
- }
-
- if (IS_G4X(dev)) {
- u16 gcfgc;
-
- /* Adjust render clock... */
- pci_read_config_word(dev-pdev, GCFGC, gcfgc);
-
- /* Down to minimum... */
- gcfgc = ~GM45_GC_RENDER_CLOCK_MASK;
- gcfgc |= GM45_GC_RENDER_CLOCK_266_MHZ;
-
- pci_write_config_word(dev-pdev, GCFGC, gcfgc);
- } else if (IS_I965G(dev)) {
- u16 gcfgc;
-
- /* Adjust render clock... */
- pci_read_config_word(dev-pdev, GCFGC, gcfgc);
-
- /* Down to minimum... */
- gcfgc = ~I965_GC_RENDER_CLOCK_MASK;
- gcfgc |= I965_GC_RENDER_CLOCK_267_MHZ;
-
- pci_write_config_word(dev-pdev, GCFGC, gcfgc);
- } else if (IS_I945G(dev) || IS_I945GM(dev)) {
- u16 gcfgc;
-
- /* Adjust render clock... */
- pci_read_config_word(dev-pdev, GCFGC, gcfgc);
-
- /* Down to minimum... */
- gcfgc = ~I945_GC_RENDER_CLOCK_MASK;
- gcfgc |= I945_GC_RENDER_CLOCK_166_MHZ;
-
- pci_write_config_word(dev-pdev, GCFGC, gcfgc);
- } else if (IS_I915G(dev)) {
- u16 gcfgc;
-
- /* Adjust render clock... */
- pci_read_config_word(dev-pdev, GCFGC, gcfgc);
-
- /* Down to minimum... */
- gcfgc = ~I915_GC_RENDER_CLOCK_MASK;
- gcfgc |= I915_GC_RENDER_CLOCK_166_MHZ;
-
- pci_write_config_word(dev-pdev, GCFGC, gcfgc);
- } else if (IS_I85X(dev)) {
- u16 hpllcc;
-
- /* Adjust render clock... */
- pci_read_config_word(dev-pdev, HPLLCC, hpllcc);
-
- /* Up to maximum... */
- hpllcc = ~GC_CLOCK_CONTROL_MASK;
- hpllcc |= GC_CLOCK_133_200;
-
- pci_write_config_word(dev-pdev, HPLLCC, hpllcc);
- }
- DRM_DEBUG_DRIVER(decreasing render clock frequency\n);
-}
-
-/* Note that no increase function is needed for this - increase_renderclock()
- * will also rewrite these bits
- */
-void intel_decrease_displayclock(struct drm_device *dev)
-{
- if (IS_IRONLAKE(dev))
- return;
-
- if (IS_I945G(dev) || IS_I945GM(dev) ||
Re: [Mesa3d-dev] [mesa] Fixes after Merge branch 'glsl-pp-rework-2'
Sedat Dilek wrote: Patches already sent to dri-devel ML [1]. Forgot to CC to mesa3d-dev. - Sedat - [1] http://marc.info/?l=dri-develm=126107525213315w=2 -- Forwarded message -- From: Sedat Dilek sedat.di...@googlemail.com Date: Thu, Dec 17, 2009 at 7:21 PM Subject: [mesa] Fixes after Merge branch 'glsl-pp-rework-2' To: DRI dri-devel@lists.sourceforge.net Here two patches fixing mesa GIT master after: commit e195eab9093d2a6cf55a42b2e7789c9a381b7782 Merge branch 'glsl-pp-rework-2' (Thanks to Ghworg on IRC) - Sedat - Committed. Thanks. -Brian -- 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
[Bug 25691] New: Cannot compile DRM modules - drm_agpsupport.c fails
http://bugs.freedesktop.org/show_bug.cgi?id=25691 Summary: Cannot compile DRM modules - drm_agpsupport.c fails Product: DRI Version: DRI CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: blocker Priority: medium Component: DRM/other AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: g.fi...@mech-tron.co.uk Created an attachment (id=32157) -- (http://bugs.freedesktop.org/attachment.cgi?id=32157) Console scrollback buffer - complete Kernel 2.6.32 (Gentoo) GCC 4.4.2 glibc 2.11-r1 X (client) 7.4 X (server) 1.7.3 DRI - from CVS (today) In trying to compile the R600 DRM module, it exits with an error at drm_agpsupport.c Output looks like: CC [M] /home/gfitch/X11-drm/drm/linux-core/drm_agpsupport.o /home/gfitch/X11-drm/drm/linux-core/drm_agpsupport.c: In function ‘drm_agp_bind_pages’: /home/gfitch/X11-drm/drm/linux-core/drm_agpsupport.c:520: error: implicit declaration of function ‘phys_to_gart’ /home/gfitch/X11-drm/drm/linux-core/drm_agpsupport.c:520: warning: assignment makes pointer from integer without a cast /home/gfitch/X11-drm/drm/linux-core/drm_agpsupport.c: In function ‘drm_agp_populate’: /home/gfitch/X11-drm/drm/linux-core/drm_agpsupport.c:589: warning: assignment makes pointer from integer without a cast make[2]: *** [/home/gfitch/X11-drm/drm/linux-core/drm_agpsupport.o] Error 1 make[1]: *** [_module_/home/gfitch/X11-drm/drm/linux-core] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.32-gentoo' make: *** [modules] Error 2 A copy of the complete console session is attached. -- 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 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: [PATCH] drm/radeon/kms: add dynamic engine reclocking (V6)
W dniu 17 grudnia 2009 06:43 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/16 Rafał Miłecki zaj...@gmail.com: V2: reorganize functions, fix modesetting calls V3: rebase patch, use radeon's workqueue V4: enable on tested chipsets only, request VBLANK IRQs V5: enable PM on older hardware (IRQs, mode_fixup, dpms) V6: use separate dynpm module parameter Tested on my M82==RV620 and my new M96==RV730. Also tested on RV515 by Sedat where already posted patch for AtomBIOS's mutex was needed. How does re-clocking happen if no crtcs are active? We will want to be much more aggressive when the displays are off. Currently we treat such situation as 1 crtc active. That is something I want to improve in next patch when this one will be commitet. I hope it is not stopping issue. -- Rafał -- 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
[PATCH] drm/radeon/kms: fix legacy rmx
From 2e6ce51de78b7402f2c50b6f6c03a1c262f882d3 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 17 Dec 2009 01:24:59 -0500
Subject: [PATCH] drm/radeon/kms: fix legacy rmx
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_encoders.c|2 ++
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |5 ++---
drivers/gpu/drm/radeon/radeon_legacy_encoders.c |2 ++
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 0d1d908..3a0b750 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -233,6 +233,8 @@ static bool radeon_atom_mode_fixup(struct
drm_encoder *encoder,
if (!ASIC_IS_AVIVO(rdev)) {
adjusted_mode-hdisplay = mode-hdisplay;
adjusted_mode-vdisplay = mode-vdisplay;
+ adjusted_mode-crtc_hdisplay = mode-hdisplay;
+ adjusted_mode-crtc_vdisplay = mode-vdisplay;
}
adjusted_mode-base.id = mode_id;
}
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index b82ede9..cc27485 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -43,8 +43,7 @@ static void radeon_overscan_setup(struct drm_crtc *crtc,
}
static void radeon_legacy_rmx_mode_set(struct drm_crtc *crtc,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+ struct drm_display_mode *mode)
{
struct drm_device *dev = crtc-dev;
struct radeon_device *rdev = dev-dev_private;
@@ -1059,7 +1058,7 @@ static int radeon_crtc_mode_set(struct drm_crtc *crtc,
radeon_set_pll(crtc, adjusted_mode);
radeon_overscan_setup(crtc, adjusted_mode);
if (radeon_crtc-crtc_id == 0) {
- radeon_legacy_rmx_mode_set(crtc, mode, adjusted_mode);
+ radeon_legacy_rmx_mode_set(crtc, adjusted_mode);
} else {
if (radeon_crtc-rmx_type != RMX_OFF) {
/* FIXME: only first crtc has rmx what should we
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index df00515..981508f 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -207,6 +207,8 @@ static bool radeon_legacy_mode_fixup(struct
drm_encoder *encoder,
*adjusted_mode = *native_mode;
adjusted_mode-hdisplay = mode-hdisplay;
adjusted_mode-vdisplay = mode-vdisplay;
+ adjusted_mode-crtc_hdisplay = mode-hdisplay;
+ adjusted_mode-crtc_vdisplay = mode-vdisplay;
adjusted_mode-base.id = mode_id;
}
--
1.5.6.3
From 2e6ce51de78b7402f2c50b6f6c03a1c262f882d3 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 17 Dec 2009 01:24:59 -0500
Subject: [PATCH] drm/radeon/kms: fix legacy rmx
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_encoders.c|2 ++
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |5 ++---
drivers/gpu/drm/radeon/radeon_legacy_encoders.c |2 ++
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c
index 0d1d908..3a0b750 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -233,6 +233,8 @@ static bool radeon_atom_mode_fixup(struct drm_encoder *encoder,
if (!ASIC_IS_AVIVO(rdev)) {
adjusted_mode-hdisplay = mode-hdisplay;
adjusted_mode-vdisplay = mode-vdisplay;
+ adjusted_mode-crtc_hdisplay = mode-hdisplay;
+ adjusted_mode-crtc_vdisplay = mode-vdisplay;
}
adjusted_mode-base.id = mode_id;
}
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index b82ede9..cc27485 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -43,8 +43,7 @@ static void radeon_overscan_setup(struct drm_crtc *crtc,
}
static void radeon_legacy_rmx_mode_set(struct drm_crtc *crtc,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+ struct drm_display_mode *mode)
{
struct drm_device *dev = crtc-dev;
struct radeon_device *rdev = dev-dev_private;
@@ -1059,7 +1058,7 @@ static int radeon_crtc_mode_set(struct drm_crtc *crtc,
radeon_set_pll(crtc, adjusted_mode);
radeon_overscan_setup(crtc, adjusted_mode);
if (radeon_crtc-crtc_id == 0) {
- radeon_legacy_rmx_mode_set(crtc, mode, adjusted_mode);
+ radeon_legacy_rmx_mode_set(crtc,
[Bug 25691] Cannot compile DRM modules - drm_agpsupport.c fails
http://bugs.freedesktop.org/show_bug.cgi?id=25691 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #1 from Alex Deucher ag...@yahoo.com 2009-12-17 16:03:47 PST --- The drm modules are maintained in the kernel now. The standalone drm tree is no longer has the kernel modules. You need 2.6.30 for 2D/Xv or 2.6.32 for 3D on r600+. -- 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 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: [PATCH] drm/radeon/kms: add dynamic engine reclocking (V6)
2009/12/17 Rafał Miłecki zaj...@gmail.com: W dniu 17 grudnia 2009 06:43 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/16 Rafał Miłecki zaj...@gmail.com: V2: reorganize functions, fix modesetting calls V3: rebase patch, use radeon's workqueue V4: enable on tested chipsets only, request VBLANK IRQs V5: enable PM on older hardware (IRQs, mode_fixup, dpms) V6: use separate dynpm module parameter Tested on my M82==RV620 and my new M96==RV730. Also tested on RV515 by Sedat where already posted patch for AtomBIOS's mutex was needed. How does re-clocking happen if no crtcs are active? We will want to be much more aggressive when the displays are off. Currently we treat such situation as 1 crtc active. That is something I want to improve in next patch when this one will be commitet. I hope it is not stopping issue. The issue you won't get vblank interrupts if the crtcs are off, so no reclocking will occur. Alex -- 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
[PATCH] drm/radeon/kms: set proper default tv standard
From 106b8bbd5e695c4ebd43b7e688fab391a0e3ead4 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 17 Dec 2009 19:00:29 -0500
Subject: [PATCH] drm/radeon/kms: set proper default tv standard
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_atombios.c | 56
drivers/gpu/drm/radeon/radeon_combios.c|9 ++--
drivers/gpu/drm/radeon/radeon_connectors.c |4 +-
drivers/gpu/drm/radeon/radeon_display.c|2 +-
drivers/gpu/drm/radeon/radeon_mode.h |6 +++
5 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 12a0c76..b5912c2 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -1234,6 +1234,61 @@ bool radeon_atom_get_tv_timings(struct
radeon_device *rdev, int index,
return true;
}
+enum radeon_tv_std
+radeon_atombios_get_tv_info(struct radeon_device *rdev)
+{
+ struct radeon_mode_info *mode_info = rdev-mode_info;
+ int index = GetIndexIntoMasterTable(DATA, AnalogTV_Info);
+ uint16_t data_offset;
+ uint8_t frev, crev;
+ struct _ATOM_ANALOG_TV_INFO *tv_info;
+ enum radeon_tv_std tv_std = TV_STD_NTSC;
+
+ atom_parse_data_header(mode_info-atom_context, index, NULL, frev,
crev, data_offset);
+
+ tv_info = (struct _ATOM_ANALOG_TV_INFO
*)(mode_info-atom_context-bios + data_offset);
+
+ switch (tv_info-ucTV_BootUpDefaultStandard) {
+ case ATOM_TV_NTSC:
+ tv_std = TV_STD_NTSC;
+ DRM_INFO(Default TV standard: NTSC\n);
+ break;
+ case ATOM_TV_NTSCJ:
+ tv_std = TV_STD_NTSC_J;
+ DRM_INFO(Default TV standard: NTSC-J\n);
+ break;
+ case ATOM_TV_PAL:
+ tv_std = TV_STD_PAL;
+ DRM_INFO(Default TV standard: PAL\n);
+ break;
+ case ATOM_TV_PALM:
+ tv_std = TV_STD_PAL_M;
+ DRM_INFO(Default TV standard: PAL-M\n);
+ break;
+ case ATOM_TV_PALN:
+ tv_std = TV_STD_PAL_N;
+ DRM_INFO(Default TV standard: PAL-N\n);
+ break;
+ case ATOM_TV_PALCN:
+ tv_std = TV_STD_PAL_CN;
+ DRM_INFO(Default TV standard: PAL-CN\n);
+ break;
+ case ATOM_TV_PAL60:
+ tv_std = TV_STD_PAL_60;
+ DRM_INFO(Default TV standard: PAL-60\n);
+ break;
+ case ATOM_TV_SECAM:
+ tv_std = TV_STD_SECAM;
+ DRM_INFO(Default TV standard: SECAM\n);
+ break;
+ default:
+ tv_std = TV_STD_NTSC;
+ DRM_INFO(Unknown TV standard; defaulting to NTSC\n);
+ break;
+ }
+ return tv_std;
+}
+
struct radeon_encoder_tv_dac *
radeon_atombios_get_tv_dac_info(struct radeon_encoder *encoder)
{
@@ -1269,6 +1324,7 @@ radeon_atombios_get_tv_dac_info(struct
radeon_encoder *encoder)
dac = dac_info-ucDAC2_NTSC_DAC_Adjustment;
tv_dac-ntsc_tvdac_adj = (bg 16) | (dac 20);
+ tv_dac-tv_std = radeon_atombios_get_tv_info(rdev);
}
return tv_dac;
}
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index c5021a3..fd94dbc 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -634,11 +634,10 @@ struct radeon_encoder_primary_dac
*radeon_combios_get_primary_dac_info(struct
return p_dac;
}
-static enum radeon_tv_std
-radeon_combios_get_tv_info(struct radeon_encoder *encoder)
+enum radeon_tv_std
+radeon_combios_get_tv_info(struct radeon_device *rdev)
{
- struct drm_device *dev = encoder-base.dev;
- struct radeon_device *rdev = dev-dev_private;
+ struct drm_device *dev = rdev-ddev;
uint16_t tv_info;
enum radeon_tv_std tv_std = TV_STD_NTSC;
@@ -779,7 +778,7 @@ struct radeon_encoder_tv_dac
*radeon_combios_get_tv_dac_info(struct
tv_dac-ntsc_tvdac_adj = (bg 16) | (dac 20);
found = 1;
}
- tv_dac-tv_std = radeon_combios_get_tv_info(encoder);
+ tv_dac-tv_std = radeon_combios_get_tv_info(rdev);
}
if (!found) {
/* then check CRT table */
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 5eece18..8da06e1 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1171,7 +1171,7 @@ radeon_add_atom_connector(struct drm_device *dev,
1);
drm_connector_attach_property(radeon_connector-base,
Re: [PATCH] drm: convert drm_ioctl to unlocked_ioctl
On Thu, Dec 17, 2009 at 8:17 AM, Arnd Bergmann a...@arndb.de wrote: drm_ioctl is called with the Big Kernel Lock held, which shows up very high in statistics on vfs_ioctl. Moving the lock into the drm_ioctl function itself makes sure we blame the right subsystem and it gets us one step closer to eliminating the locked version of fops-ioctl. Since drm_ioctl does not require the lock itself, we only need to hold it while calling the specific handler. The 32 bit conversion handlers do not interact with any other code, so they don't need the BKL here either and can just call drm_ioctl. As a bonus, this cleans up all the other users of drm_ioctl which now no longer have to find the inode or call lock_kernel. This looks good, I've taken this and I've squashed the generic pieces of your RFC into this (i.e. I haven't modified the drivers, but just added the flag to allow the ioctls to be unlocked if the driver selects them). Do you think we should try and get this in soon, its seems like it shouldn't have any regressions unless we start switching drivers over. Dave. -- 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
[Bug 25699] New: R600: Pixel operations on front buffer have no effect
http://bugs.freedesktop.org/show_bug.cgi?id=25699 Summary: R600: Pixel operations on front buffer have no effect Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: monr...@gmail.com Pixel operations (glBitmap/glDrawPixels/glCopyPixels) have no effect when operated on the front buffer. Can be tested with these single-buffered applications: progs/redbook/drawf progs/redbook/font progs/redbook/image Or by selecting the front buffer in these double-buffered applications: progs/demos/copypix progs/demos/drawpix progs/demos/readpix -- 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 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
[Bug 13683] Internal Laptopdisplay blurrys to white screen after enabling modesetting on Radeon X700 Mobility
http://bugzilla.kernel.org/show_bug.cgi?id=13683 --- Comment #35 from Jan Kreuzer kontrolla...@gmx.de 2009-12-16 09:36:36 --- You rock ! ;-) Using git of today it magically works. I dont know which commit fixed it, however i tested some options. Using r4xx_modeset=1 whitescreen (with and without new_pll option). Using r4xx_modeset=0 it works (with and without new_pll option). Should i close this bug now ? Sidenote, Although KMS works, 3D is dogslow and logging into KDE4 crashes the system. Greetings and many Thanks Jan -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- 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
[Bug 25699] R600: Pixel operations on front buffer have no effect
http://bugs.freedesktop.org/show_bug.cgi?id=25699 --- Comment #1 from Dave Airlie airl...@freedesktop.org 2009-12-17 20:39:35 PST --- should be fixed in mesa master now. -- 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 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
[Bug 25699] R600: Pixel operations on front buffer have no effect
http://bugs.freedesktop.org/show_bug.cgi?id=25699 --- Comment #2 from Rafael Monica monr...@gmail.com 2009-12-17 21:04:30 PST --- Yes, I can confirm that it's fixed in mesa master, thanks. -- 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 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
[Bug 25699] R600: Pixel operations on front buffer have no effect
http://bugs.freedesktop.org/show_bug.cgi?id=25699 Rafael Monica monr...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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 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
