Re: pulling over ttm interface changes
On 6/10/07, Thomas Hellström [EMAIL PROTECTED] wrote: Dave Airlie wrote: Anyone objections to pulling over the ttm interface ioctl changes? These are going to be annoying no matter when I do it .. so I'd like to get it out of the way.. Dave. Dave, can you give me a day or so to review? What's the verdict? :) Is it good to merge? Kristian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: pulling over ttm interface changes
Dave Airlie wrote: cheers, Kristian Kristian, This is OK with me. It will add an extra malloc / free for every buffer object creation / destruction, but will make it easier to maintain in the future, (and we can get rid of the padding for future expansion). Exactly, I took out the pad fields in the patch. I think it's a reasonable tradeoff, since we have a library abstraction barrier here and the objects aren't tiny to begin with. I can't see any problems with this, who has the time to do it? I'm up the walls with real life.. Same here. However, we don't strictly need to change the libdrm user-space interface right now. If we focus on getting the kernel TTM code in shape at this point, we can change libdrm at a later point, bumping its major version. The dl code should automatically load the correct version so we won't really have to bother about the next big incompatibility. That would mean we can merge the ttm-cleanup branch after a ioctl arg size check. I'll see if I can do that tonight. /Thomas Dave. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: pulling over ttm interface changes
On 6/14/07, Thomas Hellström [EMAIL PROTECTED] wrote: Dave Airlie wrote: cheers, Kristian Kristian, This is OK with me. It will add an extra malloc / free for every buffer object creation / destruction, but will make it easier to maintain in the future, (and we can get rid of the padding for future expansion). Exactly, I took out the pad fields in the patch. I think it's a reasonable tradeoff, since we have a library abstraction barrier here and the objects aren't tiny to begin with. I can't see any problems with this, who has the time to do it? I'm up the walls with real life.. Same here. However, we don't strictly need to change the libdrm user-space interface right now. If we focus on getting the kernel TTM code in shape at this point, we can change libdrm at a later point, bumping its major version. The dl code should automatically load the correct version so we won't really have to bother about the next big incompatibility. True. And if we bump libdrm major version, we can drop the hash table and skip lists too. With DRI interface changes, I moved the hash table implementation into libGL, the only place it's used. Kristian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: pulling over ttm interface changes
Kristian Høgsberg wrote: On 6/14/07, Thomas Hellström [EMAIL PROTECTED] wrote: Dave Airlie wrote: cheers, Kristian Kristian, This is OK with me. It will add an extra malloc / free for every buffer object creation / destruction, but will make it easier to maintain in the future, (and we can get rid of the padding for future expansion). Exactly, I took out the pad fields in the patch. I think it's a reasonable tradeoff, since we have a library abstraction barrier here and the objects aren't tiny to begin with. I can't see any problems with this, who has the time to do it? I'm up the walls with real life.. Same here. However, we don't strictly need to change the libdrm user-space interface right now. If we focus on getting the kernel TTM code in shape at this point, we can change libdrm at a later point, bumping its major version. The dl code should automatically load the correct version so we won't really have to bother about the next big incompatibility. True. And if we bump libdrm major version, we can drop the hash table and skip lists too. With DRI interface changes, I moved the hash table implementation into libGL, the only place it's used. Kristian Aargh. :) It's used in the XvMC drivers for DRI drawable tracking (At least VIA), although one can argue whether it really belongs in libdrm. /Thomas - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: pulling over ttm interface changes
On 6/14/07, Thomas Hellström [EMAIL PROTECTED] wrote: Kristian Høgsberg wrote: ... True. And if we bump libdrm major version, we can drop the hash table and skip lists too. With DRI interface changes, I moved the hash table implementation into libGL, the only place it's used. Kristian Aargh. :) It's used in the XvMC drivers for DRI drawable tracking (At least VIA), although one can argue whether it really belongs in libdrm. Can't you just use a regular X resource class there? We're tracking DRI drawables in AIGLX too, but we call CreateNewResourceType to create the resource and then track them using AddResource and LookupIDByType. Kristian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: pulling over ttm interface changes
Kristian Høgsberg wrote: On 6/14/07, Thomas Hellström [EMAIL PROTECTED] wrote: Kristian Høgsberg wrote: ... True. And if we bump libdrm major version, we can drop the hash table and skip lists too. With DRI interface changes, I moved the hash table implementation into libGL, the only place it's used. Kristian Aargh. :) It's used in the XvMC drivers for DRI drawable tracking (At least VIA), although one can argue whether it really belongs in libdrm. Can't you just use a regular X resource class there? We're tracking DRI drawables in AIGLX too, but we call CreateNewResourceType to create the resource and then track them using AddResource and LookupIDByType. Hmm, These are X Server side functions, right? I was referring to the XvMC client libs. They are DRI clients just like Mesa, and use the DRI side client protocol in the same way, only for video instead of 3D. Currently there is no client side library for the dri protocol, so at least the via library is duplicating (with small modifications) the DRI client side protocol code Mesa is using. Currently i810 XvMC is using libdrm but not the DRI protocol. Via XvMC is using both. And there are or will probably be some closed source variants out there as well. So we should not assume that Mesa is the only DRI- or libdrm client. If libdrm is changed we need to update those clients as well. One way to make this cleaner is probably to separate out the DRI client protocol and drawable tracking into a separate libdriclient.so which is linked to by any client requiring DRI functionality. That would mean (referring to via XvMC file naming here), xf86dri.c, xf86dri.h, xf86dristr.h and perhaps driDrawable.c and the corresponding Mesa files. /Thomas Kristian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: pulling over ttm interface changes
cheers, Kristian Kristian, This is OK with me. It will add an extra malloc / free for every buffer object creation / destruction, but will make it easier to maintain in the future, (and we can get rid of the padding for future expansion). Exactly, I took out the pad fields in the patch. I think it's a reasonable tradeoff, since we have a library abstraction barrier here and the objects aren't tiny to begin with. I can't see any problems with this, who has the time to do it? I'm up the walls with real life.. Dave. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: pulling over ttm interface changes
Dave Airlie wrote: Anyone objections to pulling over the ttm interface ioctl changes? These are going to be annoying no matter when I do it .. so I'd like to get it out of the way.. Dave. OK, so I've pushed some changes, the most important of which are ioctl arg support for tiled buffers, 64-bit alignment and 64-bit buffer object flag members. Mesa will need a recompilation with the new libdrm headers, since I've changed the type of the function arguments to drmBOCreate and drmBOValdate. Also perhaps we should really verify the size of the ioctl args on an x86-64 and a ia32 system. /Thomas - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: pulling over ttm interface changes
On 6/12/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Dave Airlie wrote:
Anyone objections to pulling over the ttm interface ioctl changes?
These are going to be annoying no matter when I do it .. so I'd like
to get it out of the way..
Dave.
OK, so I've pushed some changes, the most important of which are ioctl
arg support for tiled buffers, 64-bit alignment and 64-bit buffer object
flag members.
Mesa will need a recompilation with the new libdrm headers, since I've
changed the type of the function arguments to
drmBOCreate and drmBOValdate.
I was reviewing the xf86mm.h interface, and I was wondering, do we
really need to put the structs in the header? Could we get away with
just adding a couple of accessor functions and then keeping the
structs opaque? I don't which fields of the fence and bo structs are
internal details and which are to be accessed by users of the library.
Something like the attached patch, modulo a couple couple of accessor
functions?
cheers,
Kristian
diff --git a/libdrm/Makefile.am b/libdrm/Makefile.am
index e7e07e4..6fad3e1 100644
--- a/libdrm/Makefile.am
+++ b/libdrm/Makefile.am
@@ -23,7 +23,8 @@ libdrm_ladir = $(libdir)
libdrm_la_LDFLAGS = -version-number 2:3:0 -no-undefined
AM_CFLAGS = -I$(top_srcdir)/shared-core
-libdrm_la_SOURCES = xf86drm.c xf86drmHash.c xf86drmRandom.c xf86drmSL.c
+libdrm_la_SOURCES = \
+ xf86drm.c xf86drmHash.c xf86drmRandom.c xf86drmSL.c internal.h
libdrmincludedir = ${includedir}
libdrminclude_HEADERS = xf86drm.h xf86mm.h
diff --git a/libdrm/internal.h b/libdrm/internal.h
new file mode 100644
index 000..2ac67f2
--- /dev/null
+++ b/libdrm/internal.h
@@ -0,0 +1,127 @@
+/**
+ *
+ * Copyright 2006 Tungsten Graphics, Inc., Bismarck, ND. USA.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ *
+ **/
+
+#ifndef _INTERNAL_H_
+#define _INTERNAL_H_
+
+/*
+ * List macros heavily inspired by the Linux kernel
+ * list handling. No list looping yet.
+ */
+
+typedef struct _drmMMListHead
+{
+struct _drmMMListHead *prev;
+struct _drmMMListHead *next;
+} drmMMListHead;
+
+#define DRMINITLISTHEAD(__item) \
+ do{ \
+(__item)-prev = (__item); \
+(__item)-next = (__item); \
+ } while (0)
+
+#define DRMLISTADD(__item, __list) \
+ do { \
+(__item)-prev = (__list); \
+(__item)-next = (__list)-next; \
+(__list)-next-prev = (__item); \
+(__list)-next = (__item); \
+ } while (0)
+
+#define DRMLISTADDTAIL(__item, __list) \
+ do { \
+(__item)-next = (__list); \
+(__item)-prev = (__list)-prev; \
+(__list)-prev-next = (__item); \
+(__list)-prev = (__item); \
+ } while(0)
+
+#define DRMLISTDEL(__item) \
+ do { \
+(__item)-prev-next = (__item)-next; \
+(__item)-next-prev = (__item)-prev; \
+ } while(0)
+
+#define DRMLISTDELINIT(__item) \
+ do { \
+(__item)-prev-next = (__item)-next; \
+(__item)-next-prev = (__item)-prev; \
+(__item)-next = (__item); \
+(__item)-prev = (__item); \
+ } while(0)
+
+#define DRMLISTENTRY(__type, __item, __field) \
+((__type *)(((char *) (__item)) - offsetof(__type, __field)))
+
+struct _drmFence
+{
+unsigned handle;
+int class;
+unsigned type;
+unsigned flags;
+unsigned signaled;
+};
+
+struct _drmBO
+{
+drm_bo_type_t type;
+unsigned handle;
+drm_u64_t mapHandle;
+unsigned flags;
+unsigned mask;
+unsigned mapFlags;
+unsigned long size;
+unsigned long offset;
+unsigned long start;
+unsigned replyFlags;
+unsigned fenceFlags;
+unsigned pageAlignment;
+void *virtual;
+void *mapVirtual;
+int mapCount;
+};
+
+typedef struct _drmBONode
+{
+
Re: pulling over ttm interface changes
Kristian Høgsberg wrote:
On 6/12/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Dave Airlie wrote:
Anyone objections to pulling over the ttm interface ioctl changes?
These are going to be annoying no matter when I do it .. so I'd like
to get it out of the way..
Dave.
OK, so I've pushed some changes, the most important of which are ioctl
arg support for tiled buffers, 64-bit alignment and 64-bit buffer object
flag members.
Mesa will need a recompilation with the new libdrm headers, since I've
changed the type of the function arguments to
drmBOCreate and drmBOValdate.
I was reviewing the xf86mm.h interface, and I was wondering, do we
really need to put the structs in the header? Could we get away with
just adding a couple of accessor functions and then keeping the
structs opaque? I don't which fields of the fence and bo structs are
internal details and which are to be accessed by users of the library.
Something like the attached patch, modulo a couple couple of accessor
functions?
cheers,
Kristian
Kristian,
This is OK with me. It will add an extra malloc / free for every buffer
object creation / destruction,
but will make it easier to maintain in the future, (and we can get rid
of the padding for future expansion).
However, it requires some changes to Mesa as well.
/Thomas
diff --git a/libdrm/Makefile.am b/libdrm/Makefile.am
index e7e07e4..6fad3e1 100644
--- a/libdrm/Makefile.am
+++ b/libdrm/Makefile.am
@@ -23,7 +23,8 @@ libdrm_ladir = $(libdir)
libdrm_la_LDFLAGS = -version-number 2:3:0 -no-undefined
AM_CFLAGS = -I$(top_srcdir)/shared-core
-libdrm_la_SOURCES = xf86drm.c xf86drmHash.c xf86drmRandom.c xf86drmSL.c
+libdrm_la_SOURCES = \
+ xf86drm.c xf86drmHash.c xf86drmRandom.c xf86drmSL.c internal.h
libdrmincludedir = ${includedir}
libdrminclude_HEADERS = xf86drm.h xf86mm.h
diff --git a/libdrm/internal.h b/libdrm/internal.h
new file mode 100644
index 000..2ac67f2
--- /dev/null
+++ b/libdrm/internal.h
@@ -0,0 +1,127 @@
+/**
+ *
+ * Copyright 2006 Tungsten Graphics, Inc., Bismarck, ND. USA.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY
CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ *
+ **/
+
+#ifndef _INTERNAL_H_
+#define _INTERNAL_H_
+
+/*
+ * List macros heavily inspired by the Linux kernel
+ * list handling. No list looping yet.
+ */
+
+typedef struct _drmMMListHead
+{
+struct _drmMMListHead *prev;
+struct _drmMMListHead *next;
+} drmMMListHead;
+
+#define DRMINITLISTHEAD(__item) \
+ do{ \
+(__item)-prev = (__item); \
+(__item)-next = (__item); \
+ } while (0)
+
+#define DRMLISTADD(__item, __list) \
+ do { \
+(__item)-prev = (__list); \
+(__item)-next = (__list)-next; \
+(__list)-next-prev = (__item); \
+(__list)-next = (__item); \
+ } while (0)
+
+#define DRMLISTADDTAIL(__item, __list) \
+ do { \
+(__item)-next = (__list); \
+(__item)-prev = (__list)-prev; \
+(__list)-prev-next = (__item); \
+(__list)-prev = (__item); \
+ } while(0)
+
+#define DRMLISTDEL(__item) \
+ do { \
+(__item)-prev-next = (__item)-next; \
+(__item)-next-prev = (__item)-prev; \
+ } while(0)
+
+#define DRMLISTDELINIT(__item)
Re: pulling over ttm interface changes
On 6/12/07, Thomas Hellström [EMAIL PROTECTED] wrote: Kristian Høgsberg wrote: ... I was reviewing the xf86mm.h interface, and I was wondering, do we really need to put the structs in the header? Could we get away with just adding a couple of accessor functions and then keeping the structs opaque? I don't which fields of the fence and bo structs are internal details and which are to be accessed by users of the library. Something like the attached patch, modulo a couple couple of accessor functions? cheers, Kristian Kristian, This is OK with me. It will add an extra malloc / free for every buffer object creation / destruction, but will make it easier to maintain in the future, (and we can get rid of the padding for future expansion). Exactly, I took out the pad fields in the patch. I think it's a reasonable tradeoff, since we have a library abstraction barrier here and the objects aren't tiny to begin with. However, it requires some changes to Mesa as well. Yeah... but only i915tex, right? Not a lot of code use this at this point so it's still a manageable change. Kristian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
pulling over ttm interface changes
Anyone objections to pulling over the ttm interface ioctl changes? These are going to be annoying no matter when I do it .. so I'd like to get it out of the way.. Dave. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: pulling over ttm interface changes
Dave Airlie wrote: Anyone objections to pulling over the ttm interface ioctl changes? These are going to be annoying no matter when I do it .. so I'd like to get it out of the way.. Dave. Dave, can you give me a day or so to review? /Thomas - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
