[Bug 20052] New: [UXA] mesa xdemo manywin fails: only the first window has animation displayed
http://bugs.freedesktop.org/show_bug.cgi?id=20052 Summary: [UXA] mesa xdemo manywin fails: only the first window has animation displayed Product: Mesa Version: unspecified Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: jian.j.z...@intel.com Created an attachment (id=22801) -- (http://bugs.freedesktop.org/attachment.cgi?id=22801) xorg.conf System Environment: -- Platform: 945gm Arch: i386 OSD:Fedora release 9 (Sulphur) Kernel: 2.6.28 Libdrm:(master)7bbd605a21200e5e4beb94f261aefe30c4e7853d Mesa: (mesa_7_4_branch)7e8f2c56c00f93ad55842dc5e3b123a1fcf74b3c Xserver: (server-1.6-branch)1f729b42d567ae9533ac0e467afc9fbc83390776 Xf86_video_intel: (master)3aa8591abfbe8db0f13912910c850fdd748808df kernel: (drm-intel-2.6.28)e1a6fcee467556a7e955fe1f7ccc134dd2f974e7 Bug detailed description: -- With UXA, start X,then run manywin n(n1), just the first window has animation displayed. But if with EXA, it will be only the last window has animation displayed. Reproduce steps: 1. xinit 2. ./manywin 10 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20052] [UXA] mesa xdemo manywin fails: only the first window has animation displayed
http://bugs.freedesktop.org/show_bug.cgi?id=20052 --- Comment #1 from zhao jian jian.j.z...@intel.com 2009-02-11 02:09:38 PST --- Created an attachment (id=22802) -- (http://bugs.freedesktop.org/attachment.cgi?id=22802) xorg.0.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20052] [UXA] mesa xdemo manywin fails: only the first window has animation displayed
http://bugs.freedesktop.org/show_bug.cgi?id=20052 --- Comment #2 from zhao jian jian.j.z...@intel.com 2009-02-11 02:09:59 PST --- Created an attachment (id=22803) -- (http://bugs.freedesktop.org/attachment.cgi?id=22803) xorg.0.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20053] New: _pbo_zcopy failure in pbo test
http://bugs.freedesktop.org/show_bug.cgi?id=20053 Summary: _pbo_zcopy failure in pbo test Product: Mesa Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: jian.j.z...@intel.com Created an attachment (id=22804) -- (http://bugs.freedesktop.org/attachment.cgi?id=22804) xorg.conf System Environment: -- Platform: 945gm Arch: i386 OSD:Fedora release 9 (Sulphur) Kernel: 2.6.28 Libdrm:(master)7bbd605a21200e5e4beb94f261aefe30c4e7853d Mesa: (mesa_7_4_branch)7e8f2c56c00f93ad55842dc5e3b123a1fcf74b3c Xserver: (server-1.6-branch)1f729b42d567ae9533ac0e467afc9fbc83390776 Xf86_video_intel: (master)3aa8591abfbe8db0f13912910c850fdd748808df kernel: (drm-intel-2.6.28)e1a6fcee467556a7e955fe1f7ccc134dd2f974e7 Bug detailed description: -- Both with UXA and EXA, start X,then run pbo, it will have the right picture displayed. But there is a _pbo_zcopy failure displayed in terminal(As the following shows). [r...@x-945gm tests]# ./pbo libGL: OpenDriver: trying /opt/X11R7/lib/dri/i915_dri.so get fences failed: -1 param: 6, val: 0 GL_VERSION = 1.4 Mesa 7.4 GL_RENDERER = Mesa DRI Intel(R) 945GM GEM 20090114 x86/MMX/SSE2 Loaded 194 by 188 image Converting RGB image to RGBA try_pbo_zcopy: failure 2 Reproduce steps: 1. xinit 2. /mesa/progs/tests/pbo -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20053] _pbo_zcopy failure in pbo test
http://bugs.freedesktop.org/show_bug.cgi?id=20053 --- Comment #1 from zhao jian jian.j.z...@intel.com 2009-02-11 02:17:43 PST --- Created an attachment (id=22805) -- (http://bugs.freedesktop.org/attachment.cgi?id=22805) xorg.0.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20038] [945GM] 32x32 GL_RGBA textures get corrupted after suspend/ resume cycle
http://bugs.freedesktop.org/show_bug.cgi?id=20038 --- Comment #10 from David Reveman dav...@novell.com 2009-02-11 07:19:26 PST --- Created an attachment (id=22824) -- (http://bugs.freedesktop.org/attachment.cgi?id=22824) mesa texobj demo without idle function -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20038] [945GM] 32x32 GL_RGBA textures get corrupted after suspend/ resume cycle
http://bugs.freedesktop.org/show_bug.cgi?id=20038 --- Comment #11 from David Reveman dav...@novell.com 2009-02-11 07:29:19 PST --- not specific to 32x32 GL_RGBA textures. can easily be reproduced with mesa's texobj demo program. it could be specific to indirect rendering only. I attached the source for this demo prog but with the idle function disabled so it only redraws when receiving expose events. suspend seems to fail completely when idle function is enabled and it's constantly redrawing but I guess that's a different issue. 1) start the attached texobj demo with LIBGL_ALWAYS_INDIRECT=1 ./texobj 2) suspend to RAM 3) resume from suspend 4) the textures used by texobj demo are now corrupt -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 19876] 3D acceleration not working on i945GM
http://bugs.freedesktop.org/show_bug.cgi?id=19876 --- Comment #1 from Bernhard Rosenkraenzer b...@arklinux.org 2009-02-11 08:29:30 PST --- Problem still present in 2.6.29-rc4 with latest patches from drm-intel-next applied. This is on an Acer Aspire One (8086:27ae - 1025:015b); there is no indication of anything going wrong in dmesg or in the output of the application even with LIBGL_DEBUG=verbose I'm starting to suspect the DRI driver is drawing on the VGA port or something else that happens to be not in use. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6009] libdri.so fails to load when built with '--disable-xinerama'
http://bugs.freedesktop.org/show_bug.cgi?id=6009 Ian Romanick i...@freedesktop.org changed: What|Removed |Added CC||mihail.zen...@gmail.com --- Comment #3 from Ian Romanick i...@freedesktop.org 2009-02-11 09:55:02 PST --- *** Bug 18067 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gem GTT mmaps..
On Friday, February 6, 2009 4:52 pm Chris Wilson wrote:
I tried it, it's not too happy. My only concern is that this now relies
on userspace to correctly call SW_FINISH (and not unmap after mmapping
the GTT_MMAP) or otherwise the object is leaked? Patch comments inline.
This one relies on munmap or exit (as it should be). I think we're leaking a
refcount somewhere, but afaict it's not caused by this patch (failing to take
a ref at mmap time leads to a panic in unpin). That leak may have been fixed
by one of your other patches, haven't updated tested yet.
- ref at map time will keep the object around so fault shouldn't fail
- additional threads will take their refs in vm_open/close
- unmap will unref and remove mmap_offset allowing object to be freed
Tested with modetest while looking at /proc/dri/...
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 6915fb8..393d2db 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -460,6 +460,26 @@ drm_gem_object_handle_free(struct kref *kref)
}
EXPORT_SYMBOL(drm_gem_object_handle_free);
+void drm_gem_vm_open(struct vm_area_struct *vma)
+{
+ struct drm_gem_object *obj = vma-vm_private_data;
+
+ drm_gem_object_reference(obj);
+}
+EXPORT_SYMBOL(drm_gem_vm_open);
+
+void drm_gem_vm_close(struct vm_area_struct *vma)
+{
+ struct drm_gem_object *obj = vma-vm_private_data;
+ struct drm_device *dev = obj-dev;
+
+ mutex_lock(dev-struct_mutex);
+ drm_gem_object_unreference(obj);
+ mutex_unlock(dev-struct_mutex);
+}
+EXPORT_SYMBOL(drm_gem_vm_close);
+
+
/**
* drm_gem_mmap - memory map routine for GEM objects
* @filp: DRM file pointer
@@ -521,6 +541,12 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
#endif
vma-vm_page_prot = __pgprot(prot);
+ /* Take a ref here so our fault handler always has an object
+* to work with. This ref will be dropped when the last
+* process does a vm_close (at munmap or exit time).
+*/
+ drm_gem_object_reference(obj);
+
vma-vm_file = filp;/* Needed for drm_vm_open() */
drm_vm_open_locked(vma);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aac12ee..a31cbdb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -94,6 +94,8 @@ static int i915_resume(struct drm_device *dev)
static struct vm_operations_struct i915_gem_vm_ops = {
.fault = i915_gem_fault,
+ .open = drm_gem_vm_open,
+ .close = drm_gem_vm_close,
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1441831..d1a031b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -607,8 +607,6 @@ int i915_gem_fault(struct vm_area_struct *vma, struct
vm_fault *vmf)
case -EAGAIN:
return VM_FAULT_OOM;
case -EFAULT:
- case -EBUSY:
- DRM_ERROR(can't insert pfn?? fault or busy...\n);
return VM_FAULT_SIGBUS;
default:
return VM_FAULT_NOPAGE;
@@ -684,6 +682,30 @@ out_free_list:
return ret;
}
+static void
+i915_gem_free_mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj-dev;
+ struct drm_i915_gem_object *obj_priv = obj-driver_private;
+ struct drm_gem_mm *mm = dev-mm_private;
+ struct drm_map_list *list;
+
+ list = obj-map_list;
+ drm_ht_remove_item(mm-offset_hash, list-hash);
+
+ if (list-file_offset_node) {
+ drm_mm_put_block(list-file_offset_node);
+ list-file_offset_node = NULL;
+ }
+
+ if (list-map) {
+ drm_free(list-map, sizeof(struct drm_map), DRM_MEM_DRIVER);
+ list-map = NULL;
+ }
+
+ obj_priv-mmap_offset = 0;
+}
+
/**
* i915_gem_get_gtt_alignment - return required GTT alignment for an object
* @obj: object to check
@@ -2885,9 +2907,6 @@ int i915_gem_init_object(struct drm_gem_object *obj)
void i915_gem_free_object(struct drm_gem_object *obj)
{
struct drm_device *dev = obj-dev;
- struct drm_gem_mm *mm = dev-mm_private;
- struct drm_map_list *list;
- struct drm_map *map;
struct drm_i915_gem_object *obj_priv = obj-driver_private;
while (obj_priv-pin_count 0)
@@ -2898,19 +2917,7 @@ void i915_gem_free_object(struct drm_gem_object *obj)
i915_gem_object_unbind(obj);
- list = obj-map_list;
- drm_ht_remove_item(mm-offset_hash, list-hash);
-
- if (list-file_offset_node) {
- drm_mm_put_block(list-file_offset_node);
- list-file_offset_node = NULL;
- }
-
- map = list-map;
- if (map) {
- drm_free(map, sizeof(*map), DRM_MEM_DRIVER);
- list-map = NULL;
- }
+
[PATCH] drm: make drm_wait_vblank return immediately for very old sequence values
Michel may want to change this a bit (make the check smaller), but I'd still
like something like this to go in. The current wait_vblank condition won't
return if the wait sequence is more than 8M behind the current counter. This
causes problems in the wraparound case, which can happen if vblank interrupts
have been disabled by the timer (after 5s of no waiters), but then re-enabled
after a DPMS event.
(An alternative fix might be to not account for lost frames between off-on
periods at all, removing the drm_update_vblank_count code entirely.)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Tested-by: Timo Aaltonen tjaal...@cc.hut.fi
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 69aa0ab..c41cba4 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -341,7 +341,7 @@ int drm_control(struct drm_device *dev, void *data,
* vblank events since the system was booted, including lost events due to
* modesetting activity.
*/
-u32 drm_vblank_count(struct drm_device *dev, int crtc)
+unsigned int drm_vblank_count(struct drm_device *dev, int crtc)
{
return atomic_read(dev-_vblank_count[crtc]);
}
@@ -522,6 +522,11 @@ out:
return ret;
}
+#define frame_after_eq(a,b) \
+ (typecheck(unsigned int, a) \
+typecheck(unsigned int, b) \
+((int)(a) - (int)(b) = 0))
+
/**
* Wait for VBLANK.
*
@@ -589,10 +594,12 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
DRM_DEBUG(waiting on vblank count %d, crtc %d\n,
vblwait-request.sequence, crtc);
dev-last_vblank_wait[crtc] = vblwait-request.sequence;
+
+ /* Wait for the sequence number to pass or IRQs to get disabled */
DRM_WAIT_ON(ret, dev-vbl_queue[crtc], 3 * DRM_HZ,
- (((drm_vblank_count(dev, crtc) -
- vblwait-request.sequence) = (1 23)) ||
-!dev-irq_enabled));
+ frame_after_eq(drm_vblank_count(dev, crtc),
+ vblwait-request.sequence) ||
+ !dev-irq_enabled);
if (ret != -EINTR) {
struct timeval now;
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20052] [UXA] mesa xdemo manywin fails: only the first window has animation displayed
http://bugs.freedesktop.org/show_bug.cgi?id=20052 Gordon Jin gordon@intel.com changed: What|Removed |Added AssignedTo|dri-|e...@anholt.net |de...@lists.sourceforge.net | --- Comment #3 from Gordon Jin gordon@intel.com 2009-02-11 17:27:35 PST --- the EXA issue was tracked at bug#18262 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] page flipping/buffer swap for DRI2
Post early, post often, right? In the interest of getting a non-broken (i.e. non-tearing) GL stack w/DRI2 I've been working on making SwapBuffers use page flipping for full screen clients (like compositing managers). This saves a full screen blit so should be a little faster than the current code. There's a big downside though: small copies aren't sync'd, so they'll still tear. I'd like to get some feedback on the idea in general before trying to fix up the code much more (there are leaks, broken rotation, too much synchronization, and other problems I'm sure). As I said, the basic idea here is to use a simple page flip if we get a SwapBuffers request for a full screen buffer. This means queueing the flip, updating X's view of the front buffer, and returning the new front back DRI2Buffers info to the client. I've hard coded the new SwapBuffers request to 2 buffers for now, but it could be extended to include a count so that we could do triple buffering in the future (or swap out other buffers, though I'm not sure why we'd need to do that). To really make the request asynchronous though, I'll need to remove the wait event emission and somehow block rendering on the new back buffer until the flip is complete, but still allow other clients private backbuffer rendering to continue. oga suggested a new swap domain to handle this; I'll look into it. We'll definitely want something similar for the CopySubBuffer extension too; right now it just blits to the real front buffer w/o any synchronization. But doing that properly will require a kernel queue and some cancellation code (what do we do if we try to cancel a queued blit due to cliprect changes but it's too late to remove it from the queue?). CopySubBuffer can be a bit friendlier power-wise, though if you have a fairly quiet display (no blinking cursors), SwapBuffers won't be horrible during idle. All these caveats aside, compiz does look pretty cool when you don't have tearing. I haven't tested video, but textured outputs should also not tear with these hacks, since they'll be rendered offscreen and then displayed by compiz at SwapBuffers time. -- Jesse Barnes, Intel Open Source Technology Center -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] dri2proto patch for SwapBuffers
Pretty simple stuff. Like I said we should probably have a buffer count in
the reply, but that's a simple change.
diff --git a/dri2proto.h b/dri2proto.h
index dc3f2d1..93c247c 100644
--- a/dri2proto.h
+++ b/dri2proto.h
@@ -48,6 +48,7 @@
#define X_DRI2DestroyDrawable 4
#define X_DRI2GetBuffers 5
#define X_DRI2CopyRegion 6
+#define X_DRI2SwapBuffers 7
typedef struct {
CARD32 attachment B32;
@@ -190,4 +191,26 @@ typedef struct {
} xDRI2CopyRegionReply;
#define sz_xDRI2CopyRegionReply32
+typedef struct {
+CARD8 reqType;
+CARD8 dri2ReqType;
+CARD16 length B16;
+CARD32 drawable B32;
+} xDRI2SwapBuffersReq;
+#define sz_xDRI2SwapBuffersReq 8
+
+typedef struct {
+BYTEtype; /* X_Reply */
+BYTEpad1;
+CARD16 sequenceNumber B16;
+CARD32 length B32;
+CARD32 pad2 B32;
+CARD32 pad3 B32;
+CARD32 pad4 B32;
+CARD32 pad5 B32;
+CARD32 pad6 B32;
+CARD32 pad7 B32;
+} xDRI2SwapBuffersReply;
+#define sz_xDRI2SwapBuffersReply 32
+
#endif
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] mesa code for dri2 swapbuffers
I'm a Mesa novice, so I'm sure there are better ways to do this. And this
only works due to Eric's recent changes to avoid a full GetBuffers call in
DRI2GetBuffers (we can just update the private list and call
intel_update_renderbuffers to pick up the new GEM names, etc.).
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 27cc1be..5a60426 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -670,6 +670,9 @@ struct __DRIdri2ExtensionRec {
__DRIcontext *shared,
void *loaderPrivate);
+void (*setBuffers)(__DRIdrawable *drawable,
+ __DRIbuffer *buffers,
+ int count);
};
#endif
diff --git a/src/glx/x11/dri2.c b/src/glx/x11/dri2.c
index f967432..f0bd6ef 100644
--- a/src/glx/x11/dri2.c
+++ b/src/glx/x11/dri2.c
@@ -299,3 +299,50 @@ void DRI2CopyRegion(Display *dpy, XID drawable,
XserverRegion region,
UnlockDisplay(dpy);
SyncHandle();
}
+
+DRI2Buffer *DRI2SwapBuffers(Display *dpy, XID drawable)
+{
+XExtDisplayInfo *info = DRI2FindDisplay(dpy);
+xDRI2SwapBuffersReq *req;
+xDRI2SwapBuffersReply rep;
+xDRI2Buffer repBuffer;
+DRI2Buffer *buffers;
+int i;
+
+XextCheckExtension (dpy, info, dri2ExtensionName, False);
+
+LockDisplay(dpy);
+GetReq(DRI2SwapBuffers, req);
+req-reqType = info-codes-major_opcode;
+req-dri2ReqType = X_DRI2SwapBuffers;
+req-drawable = drawable;
+
+if (!_XReply(dpy, (xReply *)rep, 0, xFalse)) {
+ UnlockDisplay(dpy);
+ SyncHandle();
+ return NULL;
+}
+
+/* We expect a new front back in return */
+buffers = Xmalloc(2 * sizeof(DRI2Buffer));
+if (buffers == NULL) {
+ _XEatData(dpy, 2 * sizeof repBuffer);
+ UnlockDisplay(dpy);
+ SyncHandle();
+ return NULL;
+}
+
+for (i = 0; i 2; i++) {
+ _XReadPad(dpy, (char *) repBuffer, sizeof repBuffer);
+ buffers[i].attachment = repBuffer.attachment;
+ buffers[i].name = repBuffer.name;
+ buffers[i].pitch = repBuffer.pitch;
+ buffers[i].cpp = repBuffer.cpp;
+ buffers[i].flags = repBuffer.flags;
+}
+
+UnlockDisplay(dpy);
+SyncHandle();
+
+return buffers;
+}
diff --git a/src/glx/x11/dri2.h b/src/glx/x11/dri2.h
index 356c6bc..83e27f8 100644
--- a/src/glx/x11/dri2.h
+++ b/src/glx/x11/dri2.h
@@ -67,4 +67,7 @@ extern void
DRI2CopyRegion(Display *dpy, XID drawable, XserverRegion region,
CARD32 dest, CARD32 src);
+extern DRI2Buffer *
+DRI2SwapBuffers(Display *dpy, XID drawable);
+
#endif
diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c
index b878f05..dc8e6d5 100644
--- a/src/glx/x11/dri2_glx.c
+++ b/src/glx/x11/dri2_glx.c
@@ -210,8 +210,29 @@ static void dri2CopySubBuffer(__GLXDRIdrawable *pdraw,
static void dri2SwapBuffers(__GLXDRIdrawable *pdraw)
{
__GLXDRIdrawablePrivate *priv = (__GLXDRIdrawablePrivate *) pdraw;
+__GLXscreenConfigs *psc = pdraw-psc;
+DRI2Buffer *buffers;
+int i, j;
+
+buffers = DRI2SwapBuffers(pdraw-psc-dpy, pdraw-drawable);
+if (buffers == NULL)
+ return;
+
+/* Update the front back buffer objects */
+for (j = 0; j 2; j++) {
+ for (i = 0; i priv-bufferCount; i++) {
+ if (priv-buffers[i].attachment == buffers[j].attachment) {
+ priv-buffers[i].name = buffers[j].name;
+ priv-buffers[i].pitch = buffers[j].pitch;
+ priv-buffers[i].cpp = buffers[j].cpp;
+ priv-buffers[i].flags = buffers[j].flags;
+ }
+ }
+}
+
+(*psc-dri2-setBuffers)(pdraw-driDrawable, priv-buffers, 2);
-dri2CopySubBuffer(pdraw, 0, 0, priv-width, priv-height);
+Xfree(buffers);
}
static void dri2DestroyScreen(__GLXscreenConfigs *psc)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index ae79055..75afc45 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -488,6 +488,14 @@ dri2CreateNewDrawable(__DRIscreen *screen,
return pdraw;
}
+static void
+dri2SetBuffers(__DRIdrawable *draw, __DRIbuffer *buffers, int count)
+{
+__DRIscreen *psp = draw-driScreenPriv;
+
+(*psp-DriverAPI.SetBuffers)(draw, buffers, count);
+}
+
static void
driDestroyDrawable(__DRIdrawable *pdp)
@@ -832,6 +840,7 @@ const __DRIdri2Extension driDRI2Extension = {
dri2CreateNewScreen,
dri2CreateNewDrawable,
dri2CreateNewContext,
+dri2SetBuffers,
};
/* This is the table of extensions that the loader will dlsym() for. */
diff --git a/src/mesa/drivers/dri/common/dri_util.h
b/src/mesa/drivers/dri/common/dri_util.h
index c95a5c8..2a6e1cd 100644
--- a/src/mesa/drivers/dri/common/dri_util.h
+++ b/src/mesa/drivers/dri/common/dri_util.h
@@ -225,6 +225,13 @@
Re: [PATCH] X server dri2 SwapBuffers bits
Oh yeah, haven't dealt with versioning at all. :) It would be pretty easy to
keep existing drivers (w/o SwapBuffers hooks) working by just calling
CopyRegion, but the new protocol request probably wants a version bump.
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 4e76c71..892d07f 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -131,10 +131,27 @@ __glXDRIdrawableCopySubBuffer(__GLXdrawable *drawable,
static GLboolean
__glXDRIdrawableSwapBuffers(__GLXdrawable *drawable)
{
-__GLXDRIdrawable *private = (__GLXDRIdrawable *) drawable;
+__GLXDRIdrawable *priv = (__GLXDRIdrawable *) drawable;
+DRI2BufferPtr buffers;
+int i, j;
+
+buffers = DRI2SwapBuffers(drawable-pDraw);
+if (!buffers)
+ return FALSE;
+
+/* Update the front back buffer objects */
+for (j = 0; j 2; j++) {
+ for (i = 0; i priv-count; i++) {
+ if (priv-buffers[i].attachment == buffers[j].attachment) {
+ priv-buffers[i].name = buffers[j].name;
+ priv-buffers[i].pitch = buffers[j].pitch;
+ priv-buffers[i].cpp = buffers[j].cpp;
+ priv-buffers[i].flags = buffers[j].flags;
+ }
+ }
+}
-__glXDRIdrawableCopySubBuffer(drawable, 0, 0,
- private-width, private-height);
+xfree(buffers);
return TRUE;
}
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 0f2e24b..52dc8c7 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -49,15 +49,6 @@ static DevPrivateKey dri2WindowPrivateKey =
dri2WindowPrivateKeyIndex;
static int dri2PixmapPrivateKeyIndex;
static DevPrivateKey dri2PixmapPrivateKey = dri2PixmapPrivateKeyIndex;
-typedef struct _DRI2Drawable {
-unsigned intrefCount;
-int width;
-int height;
-DRI2BufferPtr buffers;
-int bufferCount;
-unsigned intpendingSequence;
-} DRI2DrawableRec, *DRI2DrawablePtr;
-
typedef struct _DRI2Screen {
const char *driverName;
const char *deviceName;
@@ -66,6 +57,7 @@ typedef struct _DRI2Screen {
DRI2CreateBuffersProcPtrCreateBuffers;
DRI2DestroyBuffersProcPtr DestroyBuffers;
DRI2CopyRegionProcPtr CopyRegion;
+DRI2SwapBuffersProcPtr SwapBuffers;
HandleExposuresProcPtr HandleExposures;
} DRI2ScreenRec, *DRI2ScreenPtr;
@@ -76,7 +68,7 @@ DRI2GetScreen(ScreenPtr pScreen)
return dixLookupPrivate(pScreen-devPrivates, dri2ScreenPrivateKey);
}
-static DRI2DrawablePtr
+DRI2DrawablePtr
DRI2GetDrawable(DrawablePtr pDraw)
{
WindowPtrpWin;
@@ -188,6 +180,20 @@ DRI2CopyRegion(DrawablePtr pDraw, RegionPtr pRegion,
return Success;
}
+DRI2BufferPtr
+DRI2SwapBuffers(DrawablePtr pDraw)
+{
+DRI2ScreenPtr ds = DRI2GetScreen(pDraw-pScreen);
+DRI2DrawablePtr pPriv;
+
+/* FIXME: make sure drawable is double buffered */
+pPriv = DRI2GetDrawable(pDraw);
+if (pPriv == NULL)
+ return BadDrawable;
+
+return (*ds-SwapBuffers)(pDraw);
+}
+
void
DRI2DestroyDrawable(DrawablePtr pDraw)
{
@@ -264,6 +270,7 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
ds-CreateBuffers = info-CreateBuffers;
ds-DestroyBuffers = info-DestroyBuffers;
ds-CopyRegion = info-CopyRegion;
+ds-SwapBuffers= info-SwapBuffers;
dixSetPrivate(pScreen-devPrivates, dri2ScreenPrivateKey, ds);
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index 5e7fd65..a075ddc 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -44,6 +44,15 @@ typedef struct {
void *driverPrivate;
} DRI2BufferRec, *DRI2BufferPtr;
+typedef struct _DRI2Drawable {
+unsigned intrefCount;
+int width;
+int height;
+DRI2BufferPtr buffers;
+int bufferCount;
+unsigned intpendingSequence;
+} DRI2DrawableRec, *DRI2DrawablePtr;
+
typedef DRI2BufferPtr (*DRI2CreateBuffersProcPtr)(DrawablePtr pDraw,
unsigned int *attachments,
int count);
@@ -54,6 +63,7 @@ typedef void (*DRI2CopyRegionProcPtr)(DrawablePtr
pDraw,
RegionPtr pRegion,
DRI2BufferPtr pDestBuffer,
DRI2BufferPtr pSrcBuffer);
+typedef DRI2BufferPtr (*DRI2SwapBuffersProcPtr)(DrawablePtr pDraw);
typedef void (*DRI2WaitProcPtr)(WindowPtr pWin,
unsigned int sequence);
@@ -67,10 +77,13 @@ typedef struct {
DRI2CreateBuffersProcPtr CreateBuffers;
DRI2DestroyBuffersProcPtr DestroyBuffers;
Re: [PATCH] xf86-video-intel dri2 SwapBuffers bits
Obviously we shouldn't be updating the front buffer offset in the rotation
case, and I'm not sure how well resize (or other bits for that matter) will
play with the fact that pI830-front_buffer changed out from under it. The
flip should be queued from the kernel too...
diff --git a/src/i810_reg.h b/src/i810_reg.h
index e2ffba1..4c8c023 100644
--- a/src/i810_reg.h
+++ b/src/i810_reg.h
@@ -2433,6 +2433,8 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
/* Wait for Events */
#define MI_WAIT_FOR_EVENT (0x0323)
#define MI_WAIT_FOR_OVERLAY_FLIP (116)
+#define MI_WAIT_FOR_PLANE_B_FLIP (16)
+#define MI_WAIT_FOR_PLANE_A_FLIP (12)
/* Flush */
#define MI_FLUSH (0x0423)
@@ -2464,6 +2466,11 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#define ENABLE_FOG_CONST (124)
#define ENABLE_FOG_DENSITY (123)
+#define CMD_OP_DISPLAYBUFFER_INFO ((0x029)|(0x1423)|2)
+#define ASYNC_FLIP(122)
+#define DISPLAY_PLANE_A (020)
+#define DISPLAY_PLANE_B (120)
+
/*
* New regs for broadwater -- we need to split this file up sensibly somehow.
*/
diff --git a/src/i830_dri.c b/src/i830_dri.c
index f03be43..76d7711 100644
--- a/src/i830_dri.c
+++ b/src/i830_dri.c
@@ -1634,6 +1634,7 @@ I830DRI2DestroyBuffers(DrawablePtr pDraw, DRI2BufferPtr
buffers, int count)
}
}
+/* Copy from the private back buffer to the real front buffer */
static void
I830DRI2CopyRegion(DrawablePtr pDraw, RegionPtr pRegion,
DRI2BufferPtr pDestBuffer, DRI2BufferPtr pSrcBuffer)
@@ -1672,6 +1673,166 @@ I830DRI2CopyRegion(DrawablePtr pDraw, RegionPtr pRegion,
}
+static DRI2BufferPtr
+i830_get_buffer(DrawablePtr pDraw, int attachment)
+{
+DRI2DrawablePtr pPriv;
+int i;
+
+pPriv = DRI2GetDrawable(pDraw);
+if (!pPriv)
+ return NULL;
+
+for (i = 0; i pPriv-bufferCount; i++)
+ if (pPriv-buffers[i].attachment == attachment)
+ return pPriv-buffers[i];
+
+return NULL;
+}
+
+/*
+ * At flip time we need to:
+ * - pin the new front buffer
+ * - update X screen pixmap with the new front buffer info
+ * - update new back buffer info with old front buffer info
+ * - queue the flip
+ * - queue a wait so we don't clobber rendering
+ * - return the new front back buffer info
+ */
+static DRI2BufferPtr
+i830_do_pageflip(DrawablePtr pDraw)
+{
+ScreenPtr pScreen = pDraw-pScreen;
+ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
+I830Ptr pI830 = I830PTR(pScrn);
+DRI2BufferPtr buffers, dri2_front, dri2_back;
+I830DRI2BufferPrivatePtr back_priv, front_priv;
+dri_bo *front_bo, *back_bo;
+int plane = 1;
+int pitch = pScrn-displayWidth * pI830-cpp;
+
+dri2_back = i830_get_buffer(pDraw, DRI2BufferBackLeft);
+dri2_front = i830_get_buffer(pDraw, DRI2BufferFrontLeft);
+if (!dri2_back || !dri2_front)
+ return NULL;
+
+back_priv = dri2_back-driverPrivate;
+back_bo = i830_get_pixmap_bo(back_priv-pPixmap);
+
+/* This should actually be the screen pixmap */
+front_priv = dri2_front-driverPrivate;
+front_bo = i830_get_pixmap_bo(front_priv-pPixmap);
+
+/* Pin the new front ref it so the set_pixmap_bo doesn't kill it */
+dri_bo_reference(back_bo);
+dri_bo_pin(back_bo, 0);
+dri_bo_unpin(front_bo);
+
+/* Now do the swap */
+
+/*
+ * Update the DRI2 buffer with the new info:
+ * - pixmap private ptr (so we can get the buffer later)
+ * - name
+ */
+dri2_front-driverPrivate = back_priv;
+dri_bo_flink(back_bo, dri2_front-name);
+
+/* back - front */
+dri2_back-driverPrivate = front_priv;
+dri_bo_flink(front_bo, dri2_back-name);
+
+pScrn-fbOffset = back_bo-offset;
+
+BEGIN_BATCH(4);
+if (plane == 0)
+ OUT_BATCH(CMD_OP_DISPLAYBUFFER_INFO | DISPLAY_PLANE_A);
+else
+ OUT_BATCH(CMD_OP_DISPLAYBUFFER_INFO | DISPLAY_PLANE_B);
+OUT_BATCH((pitch / 8) 3); /* flip queue and/or pitch */
+OUT_BATCH(back_bo-offset | 1);
+OUT_BATCH(((pScrn-virtualX - 1) 16) | (pScrn-virtualY - 1));
+ADVANCE_BATCH();
+
+BEGIN_BATCH(2);
+if (plane == 0)
+ OUT_BATCH(MI_WAIT_FOR_EVENT | MI_WAIT_FOR_PLANE_A_FLIP);
+else
+ OUT_BATCH(MI_WAIT_FOR_EVENT | MI_WAIT_FOR_PLANE_B_FLIP);
+OUT_BATCH(0);
+ADVANCE_BATCH();
+
+buffers = xnfcalloc(sizeof(DRI2BufferRec), 2);
+buffers[0] = *dri2_front;
+buffers[1] = *dri2_back;
+
+return buffers;
+}
+
+/* Check various flip constraints (drawable parameters vs screen params) */
+static Bool
+i830_flip_ok(DrawablePtr pDraw)
+{
+ScreenPtr pScreen = pDraw-pScreen;
+ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
+
+if (pDraw-width != pScrn-virtualX)
+ return FALSE;
+if (pDraw-height != pScrn-virtualY)
+ return FALSE;
+if (pDraw-depth != pScrn-depth)
+ return FALSE;
+
+return TRUE;
+}
+
+/*
+ * DRI2SwapBuffers should try to do a
Re: [PATCH] compiz hack
(As if the other patches aren't just hacks at this point :) This just makes
compiz always do a glXSwapBuffers call rather than SubBuffer calls. Won't
play very well with framebuffer compression, but it's a start.
diff --git a/src/display.c b/src/display.c
index 23b0ba1..134f69e 100644
--- a/src/display.c
+++ b/src/display.c
@@ -1608,7 +1608,7 @@ eventLoop (void)
timeDiff = 0;
makeScreenCurrent (s);
-
+ damageScreen(s);
if (s-slowAnimations)
{
(*s-preparePaintScreen) (s,
@@ -1680,7 +1680,7 @@ eventLoop (void)
targetScreen = NULL;
targetOutput = s-outputDev[0];
- waitForVideoSync (s);
+ //waitForVideoSync (s);
if (mask COMP_SCREEN_DAMAGE_ALL_MASK)
{
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon-rewrite branch merging.
Hi, So I have a goal to get a radeon driver that works on a bufmgr and that then can be used on non-mm/mm, and also where I can make DRI2 and FBOs work. So with that in mind and not wanting to write this 3 times, I've done a major refactoring of the radeon/r200/r300 drivers. I've refactored all the: buffer management, buffer swap + copy, texture and mipmap management, command submission handling, state + atom emission dma buffers, lock code, into common files for all 3 drivers, and re-used the same code in nearly the same ways across all 3. So far I've been working on getting the legacy buffer/command code into shape so I can merge this in place of the current drivers without suffering any major regressions. Then start adding the code necessary for DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to merge, I'd like people to bash on it, and report any major regressions above the current r100/r200/r300 codebases with these drivers. In order to get the mm/dri2 stuff working, I mainly need to 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon for this stuff at all I've made wrappers that I just need to use some magic to hook up. 2. add userspace clear paths for r100/r200. 3. fix lockups from DRI2 lockless :) 4. make it go fast. Most of the code was written by Nicolai and Jerome, I've just spent 2-3 weeks moving it around the place until it works!! I've done a series of piglit regressions and I have one or two to fix, but it seems to be only a couple left. Also any suggestions for things I should use to test this? I've mainly been doing piglit + gears + ipers + openarena when I can. Dave. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] radeon-rewrite branch merging.
On Thu, 2009-02-12 at 05:29 +, Dave Airlie wrote: Hi, So I have a goal to get a radeon driver that works on a bufmgr and that then can be used on non-mm/mm, and also where I can make DRI2 and FBOs work. So with that in mind and not wanting to write this 3 times, I've done a major refactoring of the radeon/r200/r300 drivers. I've refactored all the: buffer management, buffer swap + copy, texture and mipmap management, command submission handling, state + atom emission dma buffers, lock code, into common files for all 3 drivers, and re-used the same code in nearly the same ways across all 3. So far I've been working on getting the legacy buffer/command code into shape so I can merge this in place of the current drivers without suffering any major regressions. Then start adding the code necessary for DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to merge, I'd like people to bash on it, and report any major regressions above the current r100/r200/r300 codebases with these drivers. In order to get the mm/dri2 stuff working, I mainly need to 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon for this stuff at all I've made wrappers that I just need to use some magic to hook up. 2. add userspace clear paths for r100/r200. 3. fix lockups from DRI2 lockless :) 4. make it go fast. Most of the code was written by Nicolai and Jerome, I've just spent 2-3 weeks moving it around the place until it works!! I've done a series of piglit regressions and I have one or two to fix, but it seems to be only a couple left. Also any suggestions for things I should use to test this? I've mainly been doing piglit + gears + ipers + openarena when I can. You might want to just steal intel_clear.c for the userspace clear path. Bonus points if you actually move it somewhere appropriate in Mesa. sauerbraten's a nice open-source game that works the driver a lot harder than openarena does. When you get to fbos, the gl branch of my cairo tree plus the gl branch of my cairogears tree is mostly memory management and fbo handling right now (until I fix it, then we'll hopefully need a more complicated testcase than gears to actually hit it hard). -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-rewrite branch merging.
Hi, So I have a goal to get a radeon driver that works on a bufmgr and that then can be used on non-mm/mm, and also where I can make DRI2 and FBOs work. r200 appears busted, but its wierd busted I'll blame the master merge and fix it tomorrow. Dave. So with that in mind and not wanting to write this 3 times, I've done a major refactoring of the radeon/r200/r300 drivers. I've refactored all the: buffer management, buffer swap + copy, texture and mipmap management, command submission handling, state + atom emission dma buffers, lock code, into common files for all 3 drivers, and re-used the same code in nearly the same ways across all 3. So far I've been working on getting the legacy buffer/command code into shape so I can merge this in place of the current drivers without suffering any major regressions. Then start adding the code necessary for DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to merge, I'd like people to bash on it, and report any major regressions above the current r100/r200/r300 codebases with these drivers. In order to get the mm/dri2 stuff working, I mainly need to 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon for this stuff at all I've made wrappers that I just need to use some magic to hook up. 2. add userspace clear paths for r100/r200. 3. fix lockups from DRI2 lockless :) 4. make it go fast. Most of the code was written by Nicolai and Jerome, I've just spent 2-3 weeks moving it around the place until it works!! I've done a series of piglit regressions and I have one or two to fix, but it seems to be only a couple left. Also any suggestions for things I should use to test this? I've mainly been doing piglit + gears + ipers + openarena when I can. Dave. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20038] [945GM] 32x32 GL_RGBA textures get corrupted after suspend/ resume cycle
http://bugs.freedesktop.org/show_bug.cgi?id=20038 --- Comment #12 from qwang13 quanxian.w...@intel.com 2009-02-11 23:16:44 PST --- Reproducible: 100% 1) enable that compiz is running and windows preview plug-in is enabled 2) ensure window previews show up when mouse over window list applet 3) suspend to RAM 4) resume from suspend 5) mouse over the window list applet 6) you will notice the border and shadows are not properly rendered How to enable windows preview plug-in? Anyone knows that? Also I remember 945GM will not enable compiz as default. It has some problems on 2008Q3 release. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-rewrite branch merging.
r200 appears busted, but its wierd busted I'll blame the master merge and fix it tomorrow. Okay r200 gears is back, I think it was an artifact of not getting a clean build, along with fixing some warnings. Dave. Dave. So with that in mind and not wanting to write this 3 times, I've done a major refactoring of the radeon/r200/r300 drivers. I've refactored all the: buffer management, buffer swap + copy, texture and mipmap management, command submission handling, state + atom emission dma buffers, lock code, into common files for all 3 drivers, and re-used the same code in nearly the same ways across all 3. So far I've been working on getting the legacy buffer/command code into shape so I can merge this in place of the current drivers without suffering any major regressions. Then start adding the code necessary for DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to merge, I'd like people to bash on it, and report any major regressions above the current r100/r200/r300 codebases with these drivers. In order to get the mm/dri2 stuff working, I mainly need to 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon for this stuff at all I've made wrappers that I just need to use some magic to hook up. 2. add userspace clear paths for r100/r200. 3. fix lockups from DRI2 lockless :) 4. make it go fast. Most of the code was written by Nicolai and Jerome, I've just spent 2-3 weeks moving it around the place until it works!! I've done a series of piglit regressions and I have one or two to fix, but it seems to be only a couple left. Also any suggestions for things I should use to test this? I've mainly been doing piglit + gears + ipers + openarena when I can. Dave. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
