Re: RFC: libdrm repo
On Tue, Nov 17, 2009 at 18:54:40 +0100, Stephane Marchesin wrote: Yes, but the positive side is that distros using a standard/old (about a year) kernel don't need to crawl the old libdrm repo and find the right version (in your case they have to do this ° backport stuff) ... I think that plus the fact that it makes development and merging simpler is just a reason to do it. Why would they have to do that? Newer libdrms should stay compatible with older kernels... Cheers, Julien -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch] move dereference after null check
I moved the fence dereference after the check. rdev is fence-rdev so I
moved the rdev deference as well.
This was found by static analysis so I can't say whether fence is ever
actually null but it's a good thing to do either way.
regards,
dan carpenter
Signed-off-by: Dan Carpenter erro...@gmail.com
--- orig/drivers/gpu/drm/radeon/radeon_fence.c 2009-11-16 23:48:42.0
+0200
+++ devel/drivers/gpu/drm/radeon/radeon_fence.c 2009-11-16 23:50:23.0
+0200
@@ -140,14 +140,15 @@
bool radeon_fence_signaled(struct radeon_fence *fence)
{
- struct radeon_device *rdev = fence-rdev;
+ struct radeon_device *rdev;
unsigned long irq_flags;
bool signaled = false;
- if (rdev-gpu_lockup) {
+ if (fence == NULL) {
return true;
}
- if (fence == NULL) {
+ rdev = fence-rdev;
+ if (rdev-gpu_lockup) {
return true;
}
write_lock_irqsave(fence-rdev-fence_drv.lock, irq_flags);
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: is avoiding compat ioctls possible?
Doing all these out-of-line hidden over here in a separate file just seems crazy, and I'm having trouble wondering why ppl consider it a better idea at all. The separate file is on the way out, the modern way is to use -compat_ioctl in the driver itself. Near all drivers except for a few exceptions like DRM put it into the same file. I think you should just move the code around in DRM too and drop the separate file. -Andi -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 1/5] drm/via: add pci id for VIA VX800 chipset
Dave Airlie wrote:
I think this was an mtrr missing workaround,
I think we dropped this in favour of fixing things properly, correct
me if I'm wrong.
You are right. There was a missing MTRR entry that X.org could not
successfully create.
I was using a kernel with PAT disabled (now more difficult due to:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=commitdiff;h=c03cb3149daed3e411657e3212d05ae27cf1a874
)
And with PAT disabled, the problem of the missing MTRR entry is fixed
with this patch:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=2992e545ea006992ec9dc91c4fa996ce1e15f921
So, with these two patches, the problem is fixed for me and the patch
below can be dropped. Thank you very much!
Best regards,
Thomas
Signed-off-by: Thomas Schlichter thomas.schlich...@web.de
Cc: Dave Airlie airl...@redhat.com
Cc: Eric Anholt e...@anholt.net
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
include/drm/drm_pciids.h |1 +
1 file changed, 1 insertion(+)
diff -puN
include/drm/drm_pciids.h~drm-via-add-pci-id-for-via-vx800-chipset
include/drm/drm_pciids.h ---
a/include/drm/drm_pciids.h~drm-via-add-pci-id-for-via-vx800-chipset +++
a/include/drm/drm_pciids.h
@@ -477,6 +477,7 @@
{0x1106, 0x3343, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
{0x1106, 0x3230, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_DX9_0}, \
{0x1106, 0x3157, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_PRO_GROUP_A}, \
+ {0x1106, 0x1122, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_DX9_0}, \
{0, 0, 0}
#define i810_PCI_IDS \
_
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/4] APPLE_object_purgeable: core
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
src/mesa/main/api_exec.c |6 +
src/mesa/main/bufferobj.c | 350
src/mesa/main/bufferobj.h | 11 ++
src/mesa/main/dd.h | 15 ++
src/mesa/main/dlist.c |6 +
src/mesa/main/extensions.c |4 +
src/mesa/main/mfeatures.h |1 +
src/mesa/main/mtypes.h |4 +
8 files changed, 397 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/api_exec.c b/src/mesa/main/api_exec.c
index 1559984..953dcd9 100644
--- a/src/mesa/main/api_exec.c
+++ b/src/mesa/main/api_exec.c
@@ -746,4 +746,10 @@ _mesa_init_exec_table(struct _glapi_table *exec)
/* GL_ARB_vertex_array_object */
SET_BindVertexArray(exec, _mesa_BindVertexArray);
SET_GenVertexArrays(exec, _mesa_GenVertexArrays);
+
+#if FEATURE_APPLE_object_purgeable
+ SET_ObjectPurgeableAPPLE(exec, _mesa_ObjectPurgeableAPPLE);
+ SET_ObjectUnpurgeableAPPLE(exec, _mesa_ObjectUnpurgeableAPPLE);
+ SET_GetObjectParameterivAPPLE(exec, _mesa_GetObjectParameterivAPPLE);
+#endif
}
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 52c4995..08633a9 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -37,6 +37,8 @@
#include image.h
#include context.h
#include bufferobj.h
+#include fbobject.h
+#include texobj.h
/* Debug flags */
@@ -1655,3 +1657,351 @@ _mesa_FlushMappedBufferRange(GLenum target, GLintptr
offset, GLsizeiptr length)
if (ctx-Driver.FlushMappedBufferRange)
ctx-Driver.FlushMappedBufferRange(ctx, target, offset, length, bufObj);
}
+
+#if FEATURE_APPLE_object_purgeable
+static GLenum
+_mesa_RenderObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+ struct gl_renderbuffer *bufObj;
+ GLenum retval;
+
+ bufObj = _mesa_lookup_renderbuffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glObjectUnpurgeable(name = 0x%x), name);
+ return 0;
+ }
+
+ if (bufObj-Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glObjectPurgeable(name = 0x%x) is already purgeable, name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj-Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx-Driver.ObjectPurgeable_RenderObject)
+ retval = ctx-Driver.ObjectPurgeable_RenderObject(ctx, bufObj, option);
+
+ return retval;
+}
+
+static GLenum
+_mesa_TextureObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+ struct gl_texture_object *bufObj;
+ GLenum retval;
+
+ bufObj = _mesa_lookup_texture(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glObjectPurgeable(name = 0x%x), name);
+ return 0;
+ }
+
+ if (bufObj-Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glObjectPurgeable(name = 0x%x) is already purgeable, name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj-Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx-Driver.ObjectPurgeable_TextureObject)
+ retval = ctx-Driver.ObjectPurgeable_TextureObject(ctx, bufObj, option);
+
+ return retval;
+}
+
+static GLenum
+_mesa_BufferObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+ struct gl_buffer_object *bufObj;
+ GLenum retval;
+
+ bufObj = get_buffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glObjectPurgeable(name = 0x%x), name);
+ return 0;
+ }
+
+ if (bufObj-Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glObjectPurgeable(name = 0x%x) is already purgeable, name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj-Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx-Driver.ObjectPurgeable_BufferObject)
+ retval = ctx-Driver.ObjectPurgeable_BufferObject(ctx, bufObj, option);
+
+ return retval;
+}
+
+GLenum GLAPIENTRY
+_mesa_ObjectPurgeableAPPLE(GLenum objectType, GLuint name, GLenum option)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ if (name == 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glObjectPurgeable(name = 0x%x), name);
+ return 0;
+ }
+
+ switch (option) {
+ case GL_VOLATILE_APPLE:
+ case GL_RELEASED_APPLE:
+ break;
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ glObjectPurgeable(name = 0x%x) invalid option: %d, name,
option);
+ return 0;
+ }
+
+ switch (objectType) {
+ case GL_TEXTURE:
+ return _mesa_TextureObjectPurgeable (ctx, name, option);
+ case GL_RENDERBUFFER_EXT:
+ return _mesa_RenderObjectPurgeable (ctx, name, option);
+ case GL_BUFFER_OBJECT_APPLE:
+ return _mesa_BufferObjectPurgeable (ctx, name, option);
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ glObjectPurgeable(name = 0x%x) invalid type: %d, name,
objectType);
+ return 0;
+ }
+}
+
+static GLenum
+_mesa_RenderObjectUnpurgeable(GLcontext *ctx, GLuint name, GLenum
APPLE_object_purgeable [v3]
Large correction after Ian pointed out the fundamental flaw that the various objects are separate structures and so require independent interfaces. Please review. -ickle -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/4] APPLE_object_purgeable: xml
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- src/mesa/glapi/APPLE_object_purgeable.xml | 37 + src/mesa/glapi/Makefile |1 + src/mesa/glapi/gl_API.xml |1 + 3 files changed, 39 insertions(+), 0 deletions(-) create mode 100644 src/mesa/glapi/APPLE_object_purgeable.xml diff --git a/src/mesa/glapi/APPLE_object_purgeable.xml b/src/mesa/glapi/APPLE_object_purgeable.xml new file mode 100644 index 000..62fa64a --- /dev/null +++ b/src/mesa/glapi/APPLE_object_purgeable.xml @@ -0,0 +1,37 @@ +?xml version=1.0? +!DOCTYPE OpenGLAPI SYSTEM gl_API.dtd + +OpenGLAPI +category name=GL_APPLE_object_purgeable number=371 +enum name=RELEASED_APPLE value=0x8A19/ +enum name=VOLATILE_APPLE value=0x8A1A/ +enum name=RETAINED_APPLE value=0x8A1B/ +enum name=UNDEFINED_APPLE value=0x8A1C/ +enum name=PURGEABLE_APPLEcount=1 value=0x8A1D + size name=GetObjectParameterivAPPLE count=1 mode=get/ +/enum + +enum name=BUFFER_OBJECT_APPLE value=0x85B3/ + +function name=ObjectPurgeableAPPLE offset=assign +param name=objectType type=GLenum/ +param name=name type=GLuint/ +param name=option type=GLenum/ + return type=GLenum/ +/function + +function name=ObjectUnpurgeableAPPLE offset=assign +param name=objectType type=GLenum/ +param name=name type=GLuint/ +param name=option type=GLenum/ + return type=GLenum/ +/function + +function name=GetObjectParameterivAPPLE offset=assign +param name=objectType type=GLenum/ +param name=name type=GLuint/ +param name=pname type=GLenum/ +param name=value type=GLint * output=true/ +/function +/category +/OpenGLAPI diff --git a/src/mesa/glapi/Makefile b/src/mesa/glapi/Makefile index 71bef68..ce7c4c5 100644 --- a/src/mesa/glapi/Makefile +++ b/src/mesa/glapi/Makefile @@ -56,6 +56,7 @@ API_XML = gl_API.xml \ ARB_sync.xml \ ARB_vertex_array_object.xml \ APPLE_vertex_array_object.xml \ + APPLE_object_purgeable.xml \ EXT_framebuffer_object.xml \ EXT_packed_depth_stencil.xml \ EXT_provoking_vertex.xml \ diff --git a/src/mesa/glapi/gl_API.xml b/src/mesa/glapi/gl_API.xml index 34c7746..7ff61b3 100644 --- a/src/mesa/glapi/gl_API.xml +++ b/src/mesa/glapi/gl_API.xml @@ -11974,6 +11974,7 @@ /category xi:include href=APPLE_vertex_array_object.xml xmlns:xi=http://www.w3.org/2001/XInclude/ +xi:include href=APPLE_object_purgeable.xml xmlns:xi=http://www.w3.org/2001/XInclude/ category name=GL_APPLE_ycbcr_422 number=275 enum name=YCBCR_422_APPLE value=0x85B9/ -- 1.6.5.2 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/4] APPLE_object_purgeable: intel
Implement support for purgeable objects by using the GEM madvise ioctl.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 134 -
src/mesa/drivers/dri/intel/intel_extensions.c |2 +
2 files changed, 135 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
index 669becd..069a204 100644
--- a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
@@ -31,10 +31,12 @@
#include main/macros.h
#include main/bufferobj.h
-#include intel_context.h
#include intel_blit.h
#include intel_buffer_objects.h
#include intel_batchbuffer.h
+#include intel_context.h
+#include intel_fbo.h
+#include intel_mipmap_tree.h
#include intel_regions.h
static GLboolean
@@ -586,6 +588,126 @@ intel_bufferobj_copy_subdata(GLcontext *ctx,
intel_batchbuffer_emit_mi_flush(intel-batch);
}
+#if FEATURE_APPLE_object_purgeable
+static GLenum
+intel_buffer_purgeable(GLcontext * ctx,
+ drm_intel_bo *buffer,
+ GLenum option)
+{
+ int retained = 0;
+
+ if (buffer != NULL)
+ retained = drm_intel_bo_madvise (buffer, I915_MADV_DONTNEED);
+
+ return retained ? GL_VOLATILE_APPLE : GL_RELEASED_APPLE;
+}
+
+static GLenum
+intel_buffer_object_purgeable(GLcontext * ctx,
+ struct gl_buffer_object *obj,
+ GLenum option)
+{
+ struct intel_buffer_object *intel;
+
+ intel = intel_buffer_object (obj);
+ if (intel-buffer != NULL)
+ return intel_buffer_purgeable (ctx, intel-buffer, option);
+
+ if (option == GL_RELEASED_APPLE) {
+ if (intel-sys_buffer != NULL) {
+ _mesa_free(intel-sys_buffer);
+ intel-sys_buffer = NULL;
+ }
+
+ return GL_RELEASED_APPLE;
+ } else {
+ /* XXX Create the buffer and madvise(MADV_DONTNEED)? */
+ return intel_buffer_purgeable (ctx,
+ intel_bufferobj_buffer(intel_context(ctx),
+intel, INTEL_READ),
+ option);
+ }
+}
+
+static GLenum
+intel_texture_object_purgeable(GLcontext * ctx,
+ struct gl_texture_object *obj,
+ GLenum option)
+{
+ struct intel_texture_object *intel;
+
+ intel = intel_texture_object(obj);
+ if (intel-mt == NULL || intel-mt-region == NULL)
+ return GL_RELEASED_APPLE;
+
+ return intel_buffer_purgeable (ctx, intel-mt-region-buffer, option);
+}
+
+static GLenum
+intel_render_object_purgeable(GLcontext * ctx,
+ struct gl_renderbuffer *obj,
+ GLenum option)
+{
+ struct intel_renderbuffer *intel;
+
+ intel = intel_renderbuffer(obj);
+ if (intel-region == NULL)
+ return GL_RELEASED_APPLE;
+
+ return intel_buffer_purgeable (ctx, intel-region-buffer, option);
+}
+
+static GLenum
+intel_buffer_unpurgeable(GLcontext * ctx,
+ drm_intel_bo *buffer,
+ GLenum option)
+{
+ int retained;
+
+ retained = 0;
+ if (buffer != NULL)
+ retained = drm_intel_bo_madvise (buffer, I915_MADV_WILLNEED);
+
+ return retained ? GL_RETAINED_APPLE : GL_UNDEFINED_APPLE;
+}
+
+static GLenum
+intel_buffer_object_unpurgeable(GLcontext * ctx,
+struct gl_buffer_object *obj,
+GLenum option)
+{
+ return intel_buffer_unpurgeable (ctx, intel_buffer_object (obj)-buffer,
option);
+}
+
+static GLenum
+intel_texture_object_unpurgeable(GLcontext * ctx,
+ struct gl_texture_object *obj,
+ GLenum option)
+{
+ struct intel_texture_object *intel;
+
+ intel = intel_texture_object(obj);
+ if (intel-mt == NULL || intel-mt-region == NULL)
+ return GL_UNDEFINED_APPLE;
+
+ return intel_buffer_unpurgeable (ctx, intel-mt-region-buffer, option);
+}
+
+static GLenum
+intel_render_object_unpurgeable(GLcontext * ctx,
+struct gl_renderbuffer *obj,
+GLenum option)
+{
+ struct intel_renderbuffer *intel;
+
+ intel = intel_renderbuffer(obj);
+ if (intel-region == NULL)
+ return GL_UNDEFINED_APPLE;
+
+ return intel_buffer_unpurgeable (ctx, intel-region-buffer, option);
+}
+#endif
+
void
intelInitBufferObjectFuncs(struct dd_function_table *functions)
{
@@ -599,4 +721,14 @@ intelInitBufferObjectFuncs(struct dd_function_table
*functions)
functions-FlushMappedBufferRange = intel_bufferobj_flush_mapped_range;
functions-UnmapBuffer = intel_bufferobj_unmap;
functions-CopyBufferSubData = intel_bufferobj_copy_subdata;
+
+#if FEATURE_APPLE_object_purgeable
+ functions-ObjectPurgeable_BufferObject =
Re: RFC: libdrm repo
On Tue, 2009-11-17 at 20:54 +0100, Julien Cristau wrote: On Tue, Nov 17, 2009 at 18:54:40 +0100, Stephane Marchesin wrote: Yes, but the positive side is that distros using a standard/old (about a year) kernel don't need to crawl the old libdrm repo and find the right version (in your case they have to do this ° backport stuff) ... I think that plus the fact that it makes development and merging simpler is just a reason to do it. Why would they have to do that? Newer libdrms should stay compatible with older kernels... And vice-versa. Some people install newer kernels just to have a newer driver for some particular hardware, or a bugfix somewhere. If this breaks 3D, many modern interfaces won't work (these days they are compiz, gnome-shell, or other clutter-based interface). Breaking things by upgrading a kernel is frowned upon on LKML :) Xav -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25159] New: Using s3tc causes the application to crash, or display corrupt data with git r600 driver
http://bugs.freedesktop.org/show_bug.cgi?id=25159 Summary: Using s3tc causes the application to crash, or display corrupt data with git r600 driver Product: DRI Version: DRI CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: p...@kantaka.co.uk Using the git HEAD drm-radeon-testing merged with 2.6.32-rc7, git mesa and xf86-radeon-driver (if it's relevant), I get either corrupt display or application crashes if I turn on s3tc texture compression. I'm aware that S3tc may not be supported in the radeon git driver, which is fine, but in that case it should turn it off, not crash :) I've actually had this problem for a while, but presumed it was simply that there was something odd about my hardware that wasn't supported yet, but happened to try turning off S3tc with driconf yesterday. The behaviour was the same with a non KMS drm (just using the drm kernel modules from the drm-adg5f git repository compiled against a stock Debian 2.6.3[01] kernel) except that earlier releases resulted in corrupt textures on the screen menu from quake3, followed by a crash at round start instead of the crash at startup that the current checkout gives. Hardware: 01:00.0 VGA compatible controller: ATI Technologies Inc RV730XT [Radeon HD 4670] Behaviour: With S3tc turned on, quake3 crashes on startup with a sig11, openarena crashes has to be killed from a console. Penumbra runs but displays just a single snow texture on the screen in the game. source checkouts: Mesa d3a37d93aba86ebca697169a31d88c3ef0ce34b9 xf86-video-ati 0c4710c67a2fee2061fc3da43c9f908585693cfa drm (for libdrm): c20706ffe56cc658a4814f89e391c14f6065ec57 drm-radeon-testing: 984d1f3cd3308d176d6d14588836a87c94b340da I'm using the libtxc_dxtn.so which ships with Debian unstable: it used to work find with the old r300 driver on my old hardware, but hasn't been used for a bit. The simplest solution is presumably to just forcible disable S3tc in the r600 driver, although it would be nice to have the old r300 style code back (turn on the extension, but use the external library for the actual texture compression so that there are no patent issues for mesa). cheers, Phil -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: is avoiding compat ioctls possible?
On Wednesday 18 November 2009, Andi Kleen wrote:
Doing all these out-of-line hidden over here in a separate file just
seems crazy,
and I'm having trouble wondering why ppl consider it a better idea at all.
The separate file is on the way out, the modern way is to use
-compat_ioctl in the driver itself. Near all drivers except
for a few exceptions like DRM put it into the same file.
I think you should just move the code around in DRM too
and drop the separate file.
Right. Commonly, you can simply handle the incompatible stuff in
-compat_ioctl and then call the regular function. Another way to
do it if you want to consolidate even more is to pass a flag down
the actual function and do
static int my_common_ioctl(struct my_object *my, unsigned int cmd, unsigned
long arg,
void __user *argp, int compat)
{
...
}
static long my_native_ioctl(struct file *file, unsigned int cmd, unsigned long
arg)
{
return my_commmon_ioctl(file-private_data, cmd, arg, (void __user
*)arg, 0);
}
static long my_compat_ioctl(struct file *file, unsigned int cmd, unsigned long
arg)
{
return my_commmon_ioctl(file-private_data, cmd, arg, compat_ptr(arg),
1);
}
Doing that, you can have the ioctl handling for a subsystem consolidated in one
place, just doing the copy_from_user() part separately.
For the specific case of drm, where you have a table with all the ioctls, I can
see yet another option: add another function pointer to 'struct drm_ioctl_desc'
that does the conversion, e.g.
int drm_version_compat(void __user *argp, void *kdata, int dir)
{
struct compat_drm_version __user *uversion = argp;
struct compat_drm_version cversion;
struct drm_version *version = kdata;
if (dir == IOC_IN) {
if (copy_from_user(cversion, uversion, sizeof(cversion);
return -EFAULT;
*version = (struct drm_version) {
.version_major = cversion.version_major,
.version_minor = cversion.version_minor,
.version_mpatchlevel = cversion.version_patchlevel,
.name_len = cversion.name_len,
.name = compat_ptr(cversion.name),
.date_len = cversion.date_len,
.date = compat_ptr(cversion.date),
.desc_len = cversion.desc_len,
.desc = compat_ptr(cversion.desc),
};
return 0;
} else if (dir == IOC_OUT) {
cversion = (struct drm_version) {
.version_major = version-version_major,
.version_minor = version-version_minor,
.version_mpatchlevel = version-version_patchlevel,
.name_len = version-name_len,
.name = (unsigned long)version-name,
.date_len = version-date_len,
.date = (unsigned long)version-date,
.desc_len = version-desc_len,
.desc = (unsigned long)version-desc,
};
if (copy_to_user(uversion, cversion, sizeof(cversion);
return -EFAULT;
return 0;
}
return -EINVAL;
}
static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, drm_version_compat, 0),
...
};
Arnd
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21400] GPU locked up on M26 (RV410)
http://bugs.freedesktop.org/show_bug.cgi?id=21400 Tormod Volden bugzi07.fdo.tor...@xoxy.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Tormod Volden bugzi07.fdo.tor...@xoxy.net 2009-11-18 07:30:49 PST --- No, this problem has gone away, thanks! -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25159] Using s3tc causes the application to crash, or display corrupt data with git r600 driver
http://bugs.freedesktop.org/show_bug.cgi?id=25159 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Alex Deucher ag...@yahoo.com 2009-11-18 07:55:20 PST --- *** This bug has been marked as a duplicate of bug 24047 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24047] s3tc broken on r600
http://bugs.freedesktop.org/show_bug.cgi?id=24047 Alex Deucher ag...@yahoo.com changed: What|Removed |Added CC||p...@kantaka.co.uk --- Comment #3 from Alex Deucher ag...@yahoo.com 2009-11-18 07:55:20 PST --- *** Bug 25159 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. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25163] New: HoN doesn't start on Xpress200M
http://bugs.freedesktop.org/show_bug.cgi?id=25163 Summary: HoN doesn't start on Xpress200M Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: koo...@gmail.com When I launch Heroes of Newerth I get this error: Mesa: User error: GL_INVALID_ENUM in glGetString terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_S_construct NULL not valid My video card is: RS482 [Radeon Xpress 200M] -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2 v2] drm/i915: Add intel implementation of the pageflip ioctl
Acked-by: Jakob Bornecrantz ja...@vmware.com
Acked-by: Thomas Hellström tho...@shipmail.org
Review-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Jesse Orange Smoothie Barnes jbar...@virtuousgeek.org
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
Resend to add missing acks and sob's and to fix checkpatch errors.
cheers,
Kristian
drivers/gpu/drm/i915/i915_drv.h | 12 ++
drivers/gpu/drm/i915/i915_gem.c | 64 +-
drivers/gpu/drm/i915/i915_irq.c | 19 +++-
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_display.c | 228 +-
drivers/gpu/drm/i915/intel_drv.h |4 +
6 files changed, 291 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 57204e2..224a0ab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -527,6 +527,10 @@ typedef struct drm_i915_private {
/* indicate whether the LVDS_BORDER should be enabled or not */
unsigned int lvds_border_bits;
+ struct drm_crtc *plane_to_crtc_mapping[2];
+ struct drm_crtc *pipe_to_crtc_mapping[2];
+ wait_queue_head_t pending_flip_queue;
+
/* Reclocking support */
bool render_reclock_avail;
bool lvds_downclock_avail;
@@ -626,6 +630,13 @@ struct drm_i915_gem_object {
* Advice: are the backing pages purgeable?
*/
int madv;
+
+ /**
+* Number of crtcs where this object is currently the fb, but
+* will be page flipped away on the next vblank. When it
+* reaches 0, dev_priv-pending_flip_queue will be woken up.
+*/
+ atomic_t pending_flip;
};
/**
@@ -812,6 +823,7 @@ void i915_gem_free_all_phys_object(struct drm_device *dev);
int i915_gem_object_get_pages(struct drm_gem_object *obj);
void i915_gem_object_put_pages(struct drm_gem_object *obj);
void i915_gem_release(struct drm_device * dev, struct drm_file *file_priv);
+void i915_gem_object_flush_write_domain(struct drm_gem_object *obj);
void i915_gem_shrinker_init(void);
void i915_gem_shrinker_exit(void);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index abfc27b..86511d1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2760,6 +2760,22 @@ i915_gem_object_flush_cpu_write_domain(struct
drm_gem_object *obj)
old_write_domain);
}
+void
+i915_gem_object_flush_write_domain(struct drm_gem_object *obj)
+{
+ switch (obj-write_domain) {
+ case I915_GEM_DOMAIN_GTT:
+ i915_gem_object_flush_gtt_write_domain(obj);
+ break;
+ case I915_GEM_DOMAIN_CPU:
+ i915_gem_object_flush_cpu_write_domain(obj);
+ break;
+ default:
+ i915_gem_object_flush_gpu_write_domain(obj);
+ break;
+ }
+}
+
/**
* Moves a single object to the GTT read, and possibly write domain.
*
@@ -3525,6 +3541,41 @@ i915_gem_check_execbuffer (struct
drm_i915_gem_execbuffer *exec,
return 0;
}
+static int
+i915_gem_wait_for_pending_flip(struct drm_device *dev,
+ struct drm_gem_object **object_list,
+ int count)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ struct drm_i915_gem_object *obj_priv;
+ DEFINE_WAIT(wait);
+ int i, ret = 0;
+
+ for (;;) {
+ prepare_to_wait(dev_priv-pending_flip_queue,
+ wait, TASK_INTERRUPTIBLE);
+ for (i = 0; i count; i++) {
+ obj_priv = object_list[i]-driver_private;
+ if (atomic_read(obj_priv-pending_flip) 0)
+ break;
+ }
+ if (i == count)
+ break;
+
+ if (!signal_pending(current)) {
+ mutex_unlock(dev-struct_mutex);
+ schedule();
+ mutex_lock(dev-struct_mutex);
+ continue;
+ }
+ ret = -ERESTARTSYS;
+ break;
+ }
+ finish_wait(dev_priv-pending_flip_queue, wait);
+
+ return ret;
+}
+
int
i915_gem_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -3540,7 +3591,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
int ret, ret2, i, pinned = 0;
uint64_t exec_offset;
uint32_t seqno, flush_domains, reloc_index;
- int pin_tries;
+ int pin_tries, flips;
#if WATCH_EXEC
DRM_INFO(buffers_ptr %d buffer_count %d len %08x\n,
@@ -3612,6 +3663,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
}
/* Look up object handles */
+ flips = 0;
for (i = 0; i args-buffer_count; i++) {
[Bug 24047] s3tc broken on r600
http://bugs.freedesktop.org/show_bug.cgi?id=24047 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Alex Deucher ag...@yahoo.com 2009-11-18 08:53:20 PST --- I've gone ahead and disabled compressed texture support as it's not supported yet in the driver. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24131] radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy-is_pending = bo-cref' failed
http://bugs.freedesktop.org/show_bug.cgi?id=24131 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #15 from Alex Deucher ag...@yahoo.com 2009-11-18 08:54:26 PST --- Reverted: 13b5a624b1899c457279907d58046dfb3c95addc -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: let pin routine figure out appropriate alignment
From 8adb52b4529e777d4df0356bc2c8ef5453c2322e Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@jbarnes-desktop.localdomain
Date: Wed, 18 Nov 2009 09:56:25 -0800
Subject: [PATCH] drm/i915: let pin routine figure out appropriate alignment
When this code got moved out of intel_pipe_set_base, it grew a forced
alignment of 256k, which wasn't always correct. Remove that and let the
pin routine figure out the correct alignment for the object (it should
do this in just about every case).
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 20 +---
1 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c7d5611..b4c6b40 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1193,27 +1193,9 @@ static int
intel_pin_and_fence_fb_obj(struct drm_device *dev, struct drm_gem_object *obj)
{
struct drm_i915_gem_object *obj_priv = obj-driver_private;
- u32 alignment;
int ret;
- switch (obj_priv-tiling_mode) {
- case I915_TILING_NONE:
- alignment = 64 * 1024;
- break;
- case I915_TILING_X:
- /* pin() will align the object as required by fence */
- alignment = 0;
- break;
- case I915_TILING_Y:
- /* FIXME: Is this true? */
- DRM_ERROR(Y tiled not allowed for scan out buffers\n);
- return -EINVAL;
- default:
- BUG();
- }
-
- alignment = 256 * 1024;
- ret = i915_gem_object_pin(obj, alignment);
+ ret = i915_gem_object_pin(obj, 0);
if (ret != 0)
return ret;
--
1.6.1.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: let pin routine figure out appropriate alignment
On Wed, 18 Nov 2009 18:33:30 + Chris Wilson ch...@chris-wilson.co.uk wrote: Excerpts from Jesse Barnes's message of Wed Nov 18 17:58:42 + 2009: From 8adb52b4529e777d4df0356bc2c8ef5453c2322e Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@jbarnes-desktop.localdomain Date: Wed, 18 Nov 2009 09:56:25 -0800 Subject: [PATCH] drm/i915: let pin routine figure out appropriate alignment When this code got moved out of intel_pipe_set_base, it grew a forced alignment of 256k, which wasn't always correct. Remove that and let the pin routine figure out the correct alignment for the object (it should do this in just about every case). I thought the only reason why pin() took an alignment parameter was so that we could specify a minimum alignment of 64k for untiled scan out buffers. Are we confident that this is not the case? Well there are a few other places that want a specific alignment (though mostly 4k so redundant). But yeah we do need to preserve the 64k alignment for non-tiled scanout. I'll fix up the patch. -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: let pin routine figure out appropriate alignment
Excerpts from Jesse Barnes's message of Wed Nov 18 17:58:42 + 2009: From 8adb52b4529e777d4df0356bc2c8ef5453c2322e Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@jbarnes-desktop.localdomain Date: Wed, 18 Nov 2009 09:56:25 -0800 Subject: [PATCH] drm/i915: let pin routine figure out appropriate alignment When this code got moved out of intel_pipe_set_base, it grew a forced alignment of 256k, which wasn't always correct. Remove that and let the pin routine figure out the correct alignment for the object (it should do this in just about every case). I thought the only reason why pin() took an alignment parameter was so that we could specify a minimum alignment of 64k for untiled scan out buffers. Are we confident that this is not the case? -ickle -- Chris Wilson, Intel Open Source Technology Centre -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 3/4] APPLE_object_purgeable: core
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 52c4995..08633a9 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -37,6 +37,8 @@
#include image.h
#include context.h
#include bufferobj.h
+#include fbobject.h
+#include texobj.h
/* Debug flags */
@@ -1655,3 +1657,351 @@ _mesa_FlushMappedBufferRange(GLenum target, GLintptr
offset, GLsizeiptr length)
if (ctx-Driver.FlushMappedBufferRange)
ctx-Driver.FlushMappedBufferRange(ctx, target, offset, length,
bufObj);
}
+
+#if FEATURE_APPLE_object_purgeable
+static GLenum
+_mesa_RenderObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+ struct gl_renderbuffer *bufObj;
+ GLenum retval;
+
+ bufObj = _mesa_lookup_renderbuffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glObjectUnpurgeable(name = 0x%x), name);
+ return 0;
+ }
+
+ if (bufObj-Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glObjectPurgeable(name = 0x%x) is already purgeable,
name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj-Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx-Driver.ObjectPurgeable_RenderObject)
+ retval = ctx-Driver.ObjectPurgeable_RenderObject(ctx, bufObj, option);
+
+ return retval;
+}
+
+static GLenum
+_mesa_TextureObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
Usually, only functions that are connected directly to the dispatch
table get camel case. Functions that are only used internally are
usually named _mesa_texture_object_purgeable.
I don't know if it's worth changing these. Brian may have an opinion
about this.
+{
+ struct gl_texture_object *bufObj;
+ GLenum retval;
+
+ bufObj = _mesa_lookup_texture(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glObjectPurgeable(name = 0x%x), name);
+ return 0;
+ }
+
+ if (bufObj-Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glObjectPurgeable(name = 0x%x) is already purgeable,
name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj-Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx-Driver.ObjectPurgeable_TextureObject)
+ retval = ctx-Driver.ObjectPurgeable_TextureObject(ctx, bufObj,
option);
+
+ return retval;
+}
+
+static GLenum
+_mesa_BufferObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+ struct gl_buffer_object *bufObj;
+ GLenum retval;
+
+ bufObj = get_buffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glObjectPurgeable(name = 0x%x), name);
+ return 0;
+ }
+
+ if (bufObj-Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glObjectPurgeable(name = 0x%x) is already purgeable,
name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj-Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx-Driver.ObjectPurgeable_BufferObject)
+ retval = ctx-Driver.ObjectPurgeable_BufferObject(ctx, bufObj, option);
+
+ return retval;
+}
+
+GLenum GLAPIENTRY
+_mesa_ObjectPurgeableAPPLE(GLenum objectType, GLuint name, GLenum option)
+{
+ GET_CURRENT_CONTEXT(ctx);
+
+ if (name == 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glObjectPurgeable(name = 0x%x), name);
+ return 0;
+ }
+
+ switch (option) {
+ case GL_VOLATILE_APPLE:
+ case GL_RELEASED_APPLE:
+ break;
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ glObjectPurgeable(name = 0x%x) invalid option: %d, name,
option);
+ return 0;
+ }
+
+ switch (objectType) {
+ case GL_TEXTURE:
+ return _mesa_TextureObjectPurgeable (ctx, name, option);
+ case GL_RENDERBUFFER_EXT:
+ return _mesa_RenderObjectPurgeable (ctx, name, option);
+ case GL_BUFFER_OBJECT_APPLE:
+ return _mesa_BufferObjectPurgeable (ctx, name, option);
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ glObjectPurgeable(name = 0x%x) invalid type: %d, name,
objectType);
+ return 0;
+ }
+}
+
+static GLenum
+_mesa_RenderObjectUnpurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+ struct gl_renderbuffer *bufObj;
+ GLenum retval;
+
+ bufObj = _mesa_lookup_renderbuffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glObjectUnpurgeable(name = 0x%x), name);
+ return 0;
+ }
+
+ if (! bufObj-Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glObjectUnpurgeable(name = 0x%x) object is already
\unpurged\, name);
+ return 0;
+ }
+
+ bufObj-Purgeable = GL_FALSE;
+
+ retval = GL_RETAINED_APPLE;
+ if (ctx-Driver.ObjectUnpurgeable_RenderObject)
Re: [PATCH 3/4] APPLE_object_purgeable: core
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 52c4995..08633a9 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -37,6 +37,8 @@
#include image.h
#include context.h
#include bufferobj.h
+#include fbobject.h
+#include texobj.h
/* Debug flags */
@@ -1655,3 +1657,351 @@ _mesa_FlushMappedBufferRange(GLenum target, GLintptr
offset, GLsizeiptr length)
if (ctx-Driver.FlushMappedBufferRange)
ctx-Driver.FlushMappedBufferRange(ctx, target, offset, length,
bufObj);
}
+
+#if FEATURE_APPLE_object_purgeable
+static GLenum
+_mesa_RenderObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+ struct gl_renderbuffer *bufObj;
+ GLenum retval;
+
+ bufObj = _mesa_lookup_renderbuffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glObjectUnpurgeable(name = 0x%x), name);
+ return 0;
+ }
+
+ if (bufObj-Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glObjectPurgeable(name = 0x%x) is already purgeable,
name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj-Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx-Driver.ObjectPurgeable_RenderObject)
+ retval = ctx-Driver.ObjectPurgeable_RenderObject(ctx, bufObj,
option);
+
+ return retval;
+}
+
+static GLenum
+_mesa_TextureObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
Usually, only functions that are connected directly to the dispatch
table get camel case. Functions that are only used internally are
usually named _mesa_texture_object_purgeable.
I don't know if it's worth changing these. Brian may have an opinion
about this.
Yes, that's what I'd prefer.
The idea is if you're looking for code related to glBindTexture() you
can grep for BindTexture, for example.
When I see _mesa_TextureObjectPurgeable() I'm thinking is there an
API entrypoint named glTextureObjectPurgeable()? (there isn't)
-Brian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 18212] Crash inside r300MapTexture()
http://bugs.freedesktop.org/show_bug.cgi?id=18212 Maciej Cencora m.cenc...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 13:30:09 PST --- Should be fixed on mesa_7_7_branch now, can you check? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21696] MIssing textures in some games - Driver radeon
http://bugs.freedesktop.org/show_bug.cgi?id=21696 Maciej Cencora m.cenc...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 13:32:06 PST --- Closing because of lack of user input. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22742] prey game freezes
http://bugs.freedesktop.org/show_bug.cgi?id=22742 Maciej Cencora m.cenc...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #9 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 13:54:42 PST --- It's fixed in current mesa_7_7_branch. Can you confirm? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24963] bo-space_accounted assertion failure switching render buffers
http://bugs.freedesktop.org/show_bug.cgi?id=24963 Maciej Cencora m.cenc...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 13:55:33 PST --- Should be fixed on mesa_7_7_branch. Can you confirm? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12646] Wrong colors using yuy2 and uyvy with radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=12646 --- Comment #4 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 13:59:53 PST --- Can you reproduce the bug with mesa 7.6? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17819] R300 Colourspace problem
http://bugs.freedesktop.org/show_bug.cgi?id=17819 --- Comment #2 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 14:01:45 PST --- Can you reproduce the problem with newest xf86-video-ati and mesa? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 18953] randr crashes server
http://bugs.freedesktop.org/show_bug.cgi?id=18953 --- Comment #2 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 14:03:38 PST --- Can you reproduce the bug with newer mesa,xf86-video-ati and xserver? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22532] Black background instead of transperancy in cairo-dock (openGL)
http://bugs.freedesktop.org/show_bug.cgi?id=22532 --- Comment #2 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 14:12:44 PST --- Can you reproduce the bug with mesa 7.6 or mesa_7_7_branch from git? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25156] Using wine on ati open source drivers causes rotated textures in Wow
http://bugs.freedesktop.org/show_bug.cgi?id=25156 --- Comment #3 from Jeremy Wilkins wjer...@shaw.ca 2009-11-18 14:16:56 PST --- You are right. Thank you for pointing this out. I searched everywhere for this, but did not find the answer. The problem is projectedTectures which should be disabled. There must be a problem with its implementation in 64bit because it works in 32bit with it on. I will post back to the launchpad item. Is there already an open bug report here. If so, we can mark this duplicate. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22372] radeon_mipmap_tree.c:114: compute_tex_image_offset: Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=22372 --- Comment #10 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 14:17:38 PST --- Can you check if the bug is still reproduceable on current mesa_7_7_branch? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23122] mipmap_comp_tests will cause radeon_validate_texture error
http://bugs.freedesktop.org/show_bug.cgi?id=23122 --- Comment #1 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 14:21:21 PST --- Can you check if current mesa_7_7_branch fixes the problem? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21501] Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=21501 --- Comment #1 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 14:23:54 PST --- Can you reproduce the bug on current mesa_7_7_branch? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25156] Using wine on ati open source drivers causes rotated textures in Wow
http://bugs.freedesktop.org/show_bug.cgi?id=25156 Maciej Cencora m.cenc...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Maciej Cencora m.cenc...@gmail.com 2009-11-18 14:26:22 PST --- *** This bug has been marked as a duplicate of bug 23865 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24131] radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy-is_pending = bo-cref' failed
http://bugs.freedesktop.org/show_bug.cgi?id=24131 --- Comment #16 from Tormod Volden bugzi07.fdo.tor...@xoxy.net 2009-11-18 14:52:46 PST --- I wonder if reverting that commit brought all the radeon_dma.c:210: radeonRefillCurrentDmaRegion: Assertion `dma_bo-bo-cref == 1' failed reported in https://launchpad.net/bugs/459961 though. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] DRI2 synchronization and swap bits
On Sun, 8 Nov 2009 08:16:51 +0100 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: My proposal to use a spinlock was probably rather stupid. Because of glXGetSyncValuesOML() - I830DRI2GetMSC - drmWaitVBlank - drm_wait_vblank - drm_vblank_count(), if multiple clients call glXGetSyncValuesOML() frequently, e.g., in a polling loop, i assume this could cause quite a bit of contention on a spinlock that must be acquired with minimal delay from the vblank irq handler. According to http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO, critical sections protected by spinlock_t are preemptible if one uses a realtime kernel with preempt-rt patches applied, something i'd expect my users to do frequently. Maybe i overlook something, but this sounds unhealthy if it happens while drm_vblank_count() holds the lock? It's not ideal, but I don't think it would cause many problems in practice. The lock hold times will be very small, so contention shouldn't be a big problem, but as you say if we find issues we can use a lockless method. Btw., when looking at the code in drm_irq.c in the current linux-next tree, i saw that drm_handle_vblank_events() does a e-event.sequence = seq; assignment with the current seq vblank number when retiring an event, but the special shortcut path in drm_queue_vblank_event(), which retires events immediately without queuing them if the requested vblank number has been reached or exceeded already, does not do an update e-event.sequence = seq; with the most recent seq vblank number that triggered this early retirement. This looks inconsistent to me, could this be a bug? It uses vblwait-request.sequence which should be the right number. The timestamp is definitely off though... The simple seqlock implementation might be too simple though and a ringbuffer that holds multiple hundred recent vblank timestamp samples might be better. I wonder if it would be sufficient to just track the last timestamp. Any callers interested in the last event would get a precise timestamp. Callers looking at past events could be returned a calculated value based on the time difference between the last two events? The problem is the accuracy of glXGetMscRateOML(). This value - basically the duration of a video refresh interval - gets calculated from the current video mode timing, i.e., dotclock, HTotal and VTotal. This value is only useful for userspace applications like my toolkit under the assumption that both the dotclock of the GPU and the current system clock (TSC / HPET / APIC timer / ...) are perfectly accurate and drift-free. In reality, both clocks are imperfect and drift against each other, therefore the returned nominal value of glXGetMscRateOML() is basically always a bit wrong/ inaccurate wrt. system time as used by userspace applications. Our app therefore determines the real refresh duration by a calibration loop of multiple seconds duration at startup. This works ok, but it increases startup time, can't take slow clock drift over the course of a session into account, because i can't recalibrate during a session, and the calibration is also not perfect due to the timing noise (preemption, scheduling jitter, wakeup latency after swapbuffers etc.) that affects a measurement loop in userspace. A better approach would be for Linux to measure the current video refresh interval over a certain time window, e.g., computing a moving average over a few seconds. This could be done if the vblank timestamps are logged into a ringbuffer. The ringbuffer would allow for lock-free readout of the most recent vblank timestamp from drm_vblank_count(). At the same time the system could look at all samples in the ringbuffer to compute the real duration of a video refresh interval as a average over the deltas between samples in the ringbuffer and provide an accurate and current estimate of glXGetMscRateOML() that would be better than anything we can do in userspace. That would be even better than just using the last difference, and shouldn't add too much more code. On some configurations the refresh rate will change too (for power saving reasons it may be reduced and then increased again when activity occurs) so that would have to be accounted for. Presumably we wouldn't care about the reduced rate since it implies clients aren't actively using the display. The second problem is how to reinitialize the current vblank timestamp in drm_update_vblank_count() when vblank interrupts get reenabled after they've been disabled for a long period of time? One generic way to reinitialize would be to calculate elapsed time since last known vblank timestamp from the computed vblank count diff by multiplying the count with the known duration of the video refresh interval. In that case, an accurate estimate of glXGetMscRateOML would be important, so a ringbuffer with samples would probably help.
Re: RFC: libdrm repo
On Tuesday 17 November 2009 08:33:30 Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. A number of people have already objected to these changes and have provided good reasons. Please just drop the issue. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Thu, Nov 19, 2009 at 11:54 AM, vehemens vehem...@verizon.net wrote: On Tuesday 17 November 2009 08:33:30 Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. A number of people have already objected to these changes and have provided good reasons. I think Kristian is trying to address those reasons with this proposal. Please stop being an idiot, or at least be a more constructive idiot if you insist on it. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull][optional] drm
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Just let me know if you don't pull this and I can pick out the bits that definitely need to go in (probably just the first two non-radeon-kms fixes, and the s/r ones) Non-radeon-kms changes: EDID parser fix that we had in X but not in kernel Xen page protections fix. Fix for a race in the drm_mm (only affects radeon KMS so far) radeon-kms changes: suspend-resume fixes from F-12 for AGP and certain Thinkpads tv load detect disable for troublesome chips some connectior table quirks support for external TMDS (otherwise black screen on boot) support for dual-head RN50 server cards (otherwise black screen on boot) VGA bad EDID fix Dave. drivers/gpu/drm/drm_edid.c |6 + drivers/gpu/drm/drm_gem.c |2 +- drivers/gpu/drm/drm_mm.c|9 + drivers/gpu/drm/radeon/atom.c |1 + drivers/gpu/drm/radeon/atombios_crtc.c |7 +- drivers/gpu/drm/radeon/r100.c | 13 +- drivers/gpu/drm/radeon/r300.c |6 + drivers/gpu/drm/radeon/r420.c |3 + drivers/gpu/drm/radeon/radeon.h |2 + drivers/gpu/drm/radeon/radeon_agp.c | 12 + drivers/gpu/drm/radeon/radeon_atombios.c| 25 +- drivers/gpu/drm/radeon/radeon_combios.c | 390 --- drivers/gpu/drm/radeon/radeon_connectors.c | 69 - drivers/gpu/drm/radeon/radeon_device.c |2 + drivers/gpu/drm/radeon/radeon_display.c | 29 ++- drivers/gpu/drm/radeon/radeon_encoders.c| 85 -- drivers/gpu/drm/radeon/radeon_fb.c |9 +- drivers/gpu/drm/radeon/radeon_gem.c | 10 +- drivers/gpu/drm/radeon/radeon_i2c.c | 109 +-- drivers/gpu/drm/radeon/radeon_legacy_crtc.c |5 + drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 113 drivers/gpu/drm/radeon/radeon_mode.h| 75 - drivers/gpu/drm/radeon/radeon_reg.h | 40 ++- drivers/gpu/drm/radeon/rs400.c |1 + drivers/gpu/drm/radeon/rv515.c |9 +- 25 files changed, 790 insertions(+), 242 deletions(-) commit 44c83571e8e164840e91f3cc9fdd928889ac169b Author: Michel Dänzer daen...@vmware.com Date: Wed Aug 5 00:19:51 2009 +0200 drm/radeon: Give userspace more accurate information about available memory. This patch varies from the original and just removes memory for kernel pinned objects. Signed-off-by: Michel Dänzer daen...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit bc5096a4771453929537605e564b32c534c869bf Author: Dave Airlie airl...@redhat.com Date: Wed Nov 18 13:39:34 2009 +1000 drm/radeon/kms: pick 8bpp console when 32MB or less VRAM making the pinned console smaller gives X a bit more room to play with. Signed-off-by: Dave Airlie airl...@redhat.com commit d8c8292199eaccc4163229d6e8409e139adc45dc Author: Dave Airlie airl...@redhat.com Date: Tue Oct 13 14:10:37 2009 +1000 drm/radeon/kms: add support for encoder cloning. The RN50 really needs this since its a single crtc card, however other gpus may benefit from it as well. Signed-off-by: Dave Airlie airl...@redhat.com commit 85691e025889ceaa9a6f6cf5dbf706d7b0acfd05 Author: Jerome Glisse jgli...@redhat.com Date: Tue Nov 17 14:08:55 2009 -0800 drm/radeon/kms: fix oops when set_base is call with no FB Just do nothing if crct_set_base() is called with no FB. The oops happens when the user switches between X vt or in some case when changing mode. Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Dave Airlie airl...@redhat.com commit c7e3bff327d8f5291046ff7ff0f4568dee1f0292 Author: Jeremy Fitzhardinge jer...@goop.org Date: Tue Nov 17 14:08:54 2009 -0800 drm: make sure page protections are updated after changing vm_flags Some architectures compute -vm_page_prot depending on -vm_flags, so we need to update the protections after adjusting the flags. AFAIK this only affects running X under Xen; without this patch you get lots of coloured blobs on the screen, or maybe a complete lockup. Or anything really. But that still depends on lots of out-of-tree stuff, so I don't think there are any consequences for anyone else. But it is wrong in principle. Reported-by: Jan Beulich jbeul...@novell.com Signed-off-by: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Dave Airlie airl...@redhat.com commit 173f90fad0e5e86d978eb26c54aac424152ab386 Author: Jerome Glisse jgli...@redhat.com Date: Thu Nov 12 14:13:53
[Bug 24580] Radeon: 3D apps crash if IB is not flushed
http://bugs.freedesktop.org/show_bug.cgi?id=24580 Shawn Starr shawn.st...@rogers.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Shawn Starr shawn.st...@rogers.com 2009-11-18 21:00:36 PST --- Close it, don't see this anymore. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25177] New: [r6xx][RV635] mipmap crash with secondlife
http://bugs.freedesktop.org/show_bug.cgi?id=25177
Summary: [r6xx][RV635] mipmap crash with secondlife
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: shawn.st...@rogers.com
enable VBOs with secondlife then app will crash when rendering stuff
bt:
==
#0 0x70672f25 in raise () from /lib/libc.so.6
#1 0x70675d60 in abort () from /lib/libc.so.6
#2 0x7066c04a in __assert_fail () from /lib/libc.so.6
#3 0x7fffe2d0cf4b in migrate_image_to_miptree (ctx=value optimized out,
texObj=0x5631a00)
at radeon_mipmap_tree.c:422
#4 radeon_validate_texture_miptree (ctx=value optimized out,
texObj=0x5631a00)
at radeon_mipmap_tree.c:585
#5 0x7fffe2d038ce in r600_validate_texture (ctx=0x40d0150) at
r600_texstate.c:726
#6 r600ValidateBuffers (ctx=0x40d0150) at r600_texstate.c:772
#7 0x7fffe2d00820 in r700TryDrawPrims (ctx=0x40d0150, arrays=0x40c1aa8,
prim=0x7fffd160,
nr_prims=1, ib=0x7fffd140, index_bounds_valid=value optimized out,
min_index=0, max_index=288)
at r700_render.c:879
#8 r700DrawPrims (ctx=0x40d0150, arrays=0x40c1aa8, prim=0x7fffd160,
nr_prims=1, ib=0x7fffd140,
index_bounds_valid=value optimized out, min_index=0, max_index=288) at
r700_render.c:966
#9 0x7fffe2da0aa6 in vbo_validated_drawrangeelements (ctx=0x40d0150,
mode=4,
index_bounds_valid=1 '\001', start=0, end=288, count=1536, type=5123,
indices=0x0, basevertex=0)
at vbo/vbo_exec_array.c:662
#10 0x7fffe2da0d0f in vbo_exec_DrawRangeElementsBaseVertex (mode=4,
start=0, end=288, count=1536,
type=5123, indices=0x0, basevertex=0) at vbo/vbo_exec_array.c:758
#11 0x7fffe2da0db0 in vbo_exec_DrawRangeElements (mode=4760, start=4760,
end=6, count=-1,
type=142879792, indices=0x67616d69203d3d20) at vbo/vbo_exec_array.c:775
#12 0x01920829 in LLVertexBuffer::drawRange(unsigned int, unsigned int,
unsigned int, unsigned int, unsigned int) const ()
#13 0x006b027e in LLRenderPass::pushBatch(LLDrawInfo, unsigned int,
int) ()
#14 0x006acb23 in LLRenderPass::pushBatches(unsigned int, unsigned int,
int) ()
#15 0x006bd970 in LLDrawPoolSimple::render(int) ()
#16 0x01689f95 in LLPipeline::renderGeom(LLCamera, int) ()
#17 0x0128fd22 in display(int, float, int, int) ()
#18 0x005b8201 in LLAppViewer::mainLoop() ()
#19 0x01720a59 in main ()
full bt
#3 0x7fffe2d0cf4b in migrate_image_to_miptree (ctx=value optimized out,
texObj=0x5631a00)
at radeon_mipmap_tree.c:422
dest = 0x17010d Address 0x17010d out of bounds
__PRETTY_FUNCTION__ = migrate_image_to_miptree
#4 radeon_validate_texture_miptree (ctx=value optimized out,
texObj=0x5631a00)
at radeon_mipmap_tree.c:585
dst_miptree = 0x7f6f53a
faces = 1
face = 0
level = 0
img = 0x6532110
__func__ = radeon_validate_texture_miptree
#5 0x7fffe2d038ce in r600_validate_texture (ctx=0x40d0150) at
r600_texstate.c:726
No locals.
#6 r600ValidateBuffers (ctx=0x40d0150) at r600_texstate.c:772
t = value optimized out
rmesa = 0x4017930
rrb = 0x0
i = 0
ret = value optimized out
#7 0x7fffe2d00820 in r700TryDrawPrims (ctx=0x40d0150, arrays=0x40c1aa8,
prim=0x7fffd160,
nr_prims=1, ib=0x7fffd140, index_bounds_valid=value optimized out,
min_index=0, max_index=288)
at r700_render.c:879
__func__ = r700TryDrawPrims
__warn_once = 1
#8 r700DrawPrims (ctx=0x40d0150, arrays=0x40c1aa8, prim=0x7fffd160,
nr_prims=1, ib=0x7fffd140,
index_bounds_valid=value optimized out, min_index=0, max_index=288) at
r700_render.c:966
No locals.
#9 0x7fffe2da0aa6 in vbo_validated_drawrangeelements (ctx=0x40d0150,
mode=4,
index_bounds_valid=1 '\001', start=0, end=288, count=1536, type=5123,
indices=0x0, basevertex=0)
at vbo/vbo_exec_array.c:662
ib = {count = 1536, type = 5123, obj = 0x891adc0, ptr = 0x0}
prim = {{mode = 4, indexed = 1, begin = 1, end = 1, weak = 0, pad = 0,
start = 0, count = 1536,
basevertex = 0}}
#10 0x7fffe2da0d0f in vbo_exec_DrawRangeElementsBaseVertex (mode=4,
start=0, end=288, count=1536,
type=5123, indices=0x0, basevertex=0) at vbo/vbo_exec_array.c:758
ctx = 0x40d0150
warnCount = 0
#11 0x7fffe2da0db0 in vbo_exec_DrawRangeElements (mode=4760, start=4760,
end=6, count=-1,
type=142879792, indices=0x67616d69203d3d20) at vbo/vbo_exec_array.c:775
No locals.
...
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Let
[Bug 25177] [r6xx][RV635] mipmap crash with secondlife
http://bugs.freedesktop.org/show_bug.cgi?id=25177 --- Comment #1 from Shawn Starr shawn.st...@rogers.com 2009-11-18 21:05:27 PST --- Seems to happen w or w/o VBOs enabled, setting texture memory to 256MB triggers it -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25177] [r6xx][RV635] mipmap crash with secondlife
http://bugs.freedesktop.org/show_bug.cgi?id=25177 --- Comment #2 from Shawn Starr shawn.st...@rogers.com 2009-11-18 21:07:52 PST --- Forget about memory, this is just crashing period :/ -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21501] Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=21501 --- Comment #2 from rem11_1...@yahoo.fr 2009-11-18 23:28:55 PST --- I just retest and the bug is here with a little different (and more informative ?) debug message : scourge: radeon_texture.c:875: migrate_image_to_miptree: Assertion `srclvl-size == dstlvl-size' failed. updated info : distrib : gentoo (arch amd64) Xorg-server : 1.7.1 xf86-video-ati : from git drm : from kernel 2.6.32-rc6 libdrm : from git mesa : from git branch master with KMS/DRI2 updated 1 hour ago.. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21501] Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=21501 --- Comment #3 from rem11_1...@yahoo.fr 2009-11-18 23:34:58 PST --- A little info, my card is a X1700 (rv530) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
