Re: [Dri-devel] drm_clip_rect_t vs XF86DRIClipRectRec in i810..

[Keith Whitwell]

Dave Airlie wrote:
In Keiths bunch of changes to make the drivers build in Mesa tree he
changed the i810_dri .h from using drm_+clip_rect_t to XF86DRIClipRectRec,
this break solo, if I change it back it'll probably break dri target...
which is correct?

Well, it depends...

The recent patch reverted the files in 'i810/server' to match the original 
versions of those files in XFree.  This seems like a clean thing to do, but it 
does mean that the X types make it into the driver.  We aren't immune from X 
types in the DRI client world because they are used in actual protocol 
communication with the X server, and this is one of the few cases where those 
protocol structs are much used by the driver.

Probably, the following statements are true:

	- It's not desirable to directly include headers from the 2D DDX driver in 
the DRI client driver.  In other words, anything in a server/ directory is 
probably suspect and needs review.

	- The use of X-specific datatypes should be minimized as much as possible. 
In this case, using the DRM version is a good alternative.  It would be good 
to push this choice deeper into the shared parts of the DRI client so that the 
existence of the two types with the same structure isn't even apparent to the 
drivers.

	- Modifying files in server/ isn't desirable as they are effectively imports 
from XFree86, it would be better to create a new header in the driver 
directory or use one from elsewhere (often the DRM) which has the necessary 
definitions.



Keith



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] Re: [Dri-devel] Build & use DRI drivers directly from Mesa

[Keith Whitwell]

Vladimir Dergachev wrote:
Keith - do these drivers work with XFree86 4.4.0, or do they require
something newer ?
Also, if one is starting on a new driver do you recommend using 4.4.0
codebase or something different ? (the simpler the better..)
At the moment, we're trying to get them working at all.  This is the first 
pass at doing this.  The hope is that we can get them working universally.

Keiht



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: [Mesa3d-dev] Build & use DRI drivers directly from Mesa

[Keith Whitwell]

Keith Whitwell wrote:
Ronny V. Vindenes wrote:

0x002a9579b885 in DoBindContext (dpy=0x5045a0, draw=52428802,
read=52428802, ctx=0x511070, modes=0x50c4d0, psp=0x50ed40)
at dri_util.c:480
480 DRM_SPINLOCK(&psp->pSAREA->drawable_lock,
psp->drawLockID);


OK, it looks like there might be some x86_64 magic missing to get 
spinlocks working...
Please try this diff - it will complain if no DRM_CAS is defined, which is one 
way to cause the infinite loop in DRM_SPINLOCK.

Keith

Index: src/mesa/drivers/dri/dri_client/imports/xf86drm.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/dri_client/imports/xf86drm.h,v
retrieving revision 1.1
diff -u -r1.1 xf86drm.h
--- a/src/mesa/drivers/dri/dri_client/imports/xf86drm.h 14 Apr 2004 12:39:58 - 
 1.1
+++ b/src/mesa/drivers/dri/dri_client/imports/xf86drm.h 29 Apr 2004 14:44:23 -
@@ -413,6 +413,7 @@
 #endif /* __GNUC__ >= 2 */
 
 #ifndef DRM_CAS
+#error No fast lock defined -- DRI will fail.
 #define DRM_CAS(lock,old,new,ret) do { ret=1; } while (0) /* FAST LOCK FAILS */
 #endif
 

[Dri-devel] Re: [Mesa3d-dev] Build & use DRI drivers directly from Mesa

[Keith Whitwell]

Ronny V. Vindenes wrote:

0x002a9579b885 in DoBindContext (dpy=0x5045a0, draw=52428802,
read=52428802, ctx=0x511070, modes=0x50c4d0, psp=0x50ed40)
at dri_util.c:480
480 DRM_SPINLOCK(&psp->pSAREA->drawable_lock,
psp->drawLockID);
OK, it looks like there might be some x86_64 magic missing to get spinlocks 
working...

Keith



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: [Mesa3d-dev] Build & use DRI drivers directly from Mesa

[Keith Whitwell]

Ronny V. Vindenes wrote:
tor, 29.04.2004 kl. 14.59 skrev Keith Whitwell:

I've committed a patch to allow people to build DRI drivers directly in Mesa 
CVS.  There are still a couple of gotchas, so I'm going to give some build 
instructions here:

1) Update your mesa CVS...

2) Ensure you have a checkout of DRM cvs somewhere.
3) Edit /config/linux-dri to set DRM_SOURCE_PATH to point to the DRM 
cvs tree.

4) In , type: make linux-dri
	-- This should (hopefully) build the *_dri.so files and place them in 
/lib

To use the drivers:

1) export LIBGL_DRIVERS_PATH=/lib

and then go off and run some demos to check.

I've tested a few things such as quake, tuxracer and the Mesa demos, and all 
seems well.  Additionally, I've verified that DRI cvs continues to build.



I've tried to use mesa built r200 driver but all programs hang (see
attached strace of glxinfo), and I've noticed there's a big file size
difference between the driver built in dri cvs and in mesa:
Mesa/lib64/r200_dri.so: ELF 64-bit LSB shared object, AMD x86-64,
version 1 (SYSV), not stripped
24430245 apr 29 15:25 Mesa/lib64/r200_dri.so
xc/xc/lib/GL/mesa/drivers/dri/r200/r200_dri.so: ELF 64-bit LSB shared
object, AMD x86-64, version 1 (SYSV), not stripped
15831912 apr 29 15:41 xc/xc/lib/GL/mesa/drivers/dri/r200/r200_dri.so
They look similar here, but not identical:

[EMAIL PROTECTED] lib]# ls -l r200_dri.so
-rwxr-xr-x1 root root 16259393 Apr 29 13:12 r200_dri.so*
[EMAIL PROTECTED] lib]# ls -l /home/XF4/lib/modules/dri/r200_dri.so
-r--r--r--1 root root 16454047 Apr 29 12:02 
/home/XF4/lib/modules/dri/r200_dri.so

[EMAIL PROTECTED] lib]# size /home/XF4/lib/modules/dri/r200_dri.so
   textdata bss dec hex filename
1642247   72228  143812 1858287  1c5aef /home/XF4/lib/modules/dri/r200_dri.so
[EMAIL PROTECTED] lib]# size /home/progs/xc-trunk/Mesa-newtree/lib/r200_dri.so
   textdata bss dec hex filename
2143610   82980  143812 2370402  242b62 
/home/progs/xc-trunk/Mesa-newtree/lib/r200_dri.so

How exactly does glxinfo fail?  Do you have a backtrace?

Keith



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Build & use DRI drivers directly from Mesa

[Keith Whitwell]

I've committed a patch to allow people to build DRI drivers directly in Mesa 
CVS.  There are still a couple of gotchas, so I'm going to give some build 
instructions here:

1) Update your mesa CVS...

2) Ensure you have a checkout of DRM cvs somewhere.
3) Edit /config/linux-dri to set DRM_SOURCE_PATH to point to the DRM 
cvs tree.

4) In , type: make linux-dri
	-- This should (hopefully) build the *_dri.so files and place them in 
/lib

To use the drivers:

1) export LIBGL_DRIVERS_PATH=/lib

and then go off and run some demos to check.

I've tested a few things such as quake, tuxracer and the Mesa demos, and all 
seems well.  Additionally, I've verified that DRI cvs continues to build.

Hopefully, we can start a new 'stable' Mesa branch shortly, import that into 
DRI CVS so that we can stop worrying about breaking the DRI build with every 
Mesa change.  Then, driver development can continue in the Mesa tree, the DRI 
tree will host DDX and integration development and receive periodic snapshots 
into xc/extras/Mesa, as it used to.

Keith



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] More progress building *_dri.so in Mesa tree

[Keith Whitwell]

Here's a diff that basically gets all the *_dri.so's compiling in the Mesa tree.

Unfortunately, they don't actually work, but I'm looking into that.

Keith
Index: configs/linux-dri
===
RCS file: /cvs/mesa/Mesa/configs/linux-dri,v
retrieving revision 1.1
diff -u -r1.1 linux-dri
--- a/configs/linux-dri 14 Apr 2004 12:44:07 -  1.1
+++ b/configs/linux-dri 29 Apr 2004 10:09:12 -
@@ -30,5 +30,11 @@
 PROGRAM_DIRS = 
 WINDOW_SYSTEM=dri
 
-#DRI_DIRS = dri_client gamma i810 i830 mach64 mga r128 r200 radeon sis tdfx
-DRI_DIRS = dri_client  i830
+# This kindof sucks - we only need the header files from here:
+# 
+DRM_SOURCE_PATH=/home/progs/drm
+
+# Only savage missing:
+#
+DRI_DIRS = dri_client ffb gamma i810 i830 mach64 mga r128 r200 radeon sis tdfx 
unichrome
+
Index: include/GL/internal/dri_interface.h
===
RCS file: /cvs/mesa/Mesa/include/GL/internal/dri_interface.h,v
retrieving revision 1.2
diff -u -r1.2 dri_interface.h
--- a/include/GL/internal/dri_interface.h   15 Apr 2004 01:24:57 -  1.2
+++ b/include/GL/internal/dri_interface.h   29 Apr 2004 10:09:12 -
@@ -35,6 +35,9 @@
  * \author Ian Romanick <[EMAIL PROTECTED]>
  */
 
+#ifndef DRI_INTERFACE_H
+#define DRI_INTERFACE_H
+
 /* FIXME: With a small amount of work, these two includes can be removed. */
 #include 
 #include 
@@ -497,3 +500,5 @@
  */
 unsigned swap_interval;
 };
+
+#endif
Index: src/mesa/drivers/dri/Makefile
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- a/src/mesa/drivers/dri/Makefile 14 Apr 2004 12:44:07 -  1.3
+++ b/src/mesa/drivers/dri/Makefile 29 Apr 2004 10:09:13 -
@@ -14,7 +14,9 @@
 
 
 subdirs:
+   echo $(DRI_DIRS)
@for dir in $(DRI_DIRS) ; do \
+   echo $$dir ; \
(cd $$dir ; make) || exit 1; \
done
 
Index: src/mesa/drivers/dri/Makefile.template
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/Makefile.template,v
retrieving revision 1.3
diff -u -r1.3 Makefile.template
--- a/src/mesa/drivers/dri/Makefile.template15 Apr 2004 04:50:20 -  1.3
+++ b/src/mesa/drivers/dri/Makefile.template29 Apr 2004 10:09:13 -
@@ -21,7 +21,6 @@
 WINOBJ=
 WINLIB=-L$(MESA)/src/glx/mini
 MINIGLX_INCLUDES = -I$(TOP)/src/glx/mini
-MINIGLX_SOURCES = 
 INCLUDES = $(MINIGLX_INCLUDES) \
   -I$(DRM_SOURCE_PATH)/shared \
   $(SHARED_INCLUDES)
@@ -32,12 +31,17 @@
 endif
 
 
+
+
+
 ### Include directories
 SHARED_INCLUDES = \
-I. \
-I../common \
-Iserver \
+   -I$(DRM_SOURCE_PATH)/shared \
-I$(TOP)/include \
+   -I$(TOP)/include/GL/internal \
-I$(TOP)/src/mesa \
-I$(TOP)/src/mesa/main \
-I$(TOP)/src/mesa/glapi \
@@ -59,7 +63,7 @@
 
 # TARGETS #
 
-default: depend $(LIB_DIR)/$(LIBNAME)
+default: depend symlinks $(LIB_DIR)/$(LIBNAME)
 
 
 #$(LIB_DIR)/$(LIBNAME): $(OBJECTS) $(MESA_MODULES) $(WINOBJ) Makefile
@@ -74,7 +78,6 @@
 
 
 
-
 # Run 'make depend' to update the dependencies if you change
 # what's included by any source file.
 depend: $(C_SOURCES) $(ASM_SOURCES)
@@ -90,6 +93,6 @@
 
 # Remove .o and backup files
 clean:
-   -rm -f *.o */*.o *~ *.o *~ *.so server/*.o
+   -rm -f *.o */*.o *~ *.o *~ *.so server/*.o $(SYMLINKS)
 
 include depend
Index: src/mesa/drivers/dri/dri_client/Makefile
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/dri_client/Makefile,v
retrieving revision 1.1
diff -u -r1.1 Makefile
--- a/src/mesa/drivers/dri/dri_client/Makefile  14 Apr 2004 12:39:58 -  1.1
+++ b/src/mesa/drivers/dri/dri_client/Makefile  29 Apr 2004 10:09:13 -
@@ -23,6 +23,7 @@
 
 INCLUDES = \
-I$(TOP)/include \
+   -I$(TOP)/include/GL/internal \
-I$(TOP)/src/mesa \
-I$(TOP)/src/mesa/main \
-I$(TOP)/src/mesa/glapi \
Index: src/mesa/drivers/dri/dri_client/dri_glx.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/dri_client/dri_glx.c,v
retrieving revision 1.1
diff -u -r1.1 dri_glx.c
--- a/src/mesa/drivers/dri/dri_client/dri_glx.c 14 Apr 2004 12:39:58 -  1.1
+++ b/src/mesa/drivers/dri/dri_client/dri_glx.c 29 Apr 2004 10:09:13 -
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include "extutil.h"
+#include "dri_interface.h"
 #include "glxclient.h"
 #include "xf86dri.h"
 #include "sarea.h"
Index: src/mesa/drivers/dri/dri_client/dri_util.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/dri_client/dri_util.c,v
retrieving revision 1.1
diff -u -r1.1 dri_util.c
--- a/src/mesa/drivers/dri/dri_client/dri_util.c  

[Dri-devel] Re: Wiki Update

[Keith Whitwell]

[EMAIL PROTECTED] wrote:

diff -urN /tmp/wiki.23iQYm/wiki/text/FrontPage /home/groups/d/dr/dri/wiki/text/FrontPage
--- /tmp/wiki.23iQYm/wiki/text/FrontPage	2004-04-25 04:19:27.0 -0700
+++ /home/groups/d/dr/dri/wiki/text/FrontPage	2004-04-27 02:24:02.0 -0700
@@ -49,6 +49,7 @@
   * DriHistory: DRI project history
   * CategoryCategory: categories in this Wiki
   * [http://www.xfree86.org XFree86 ]
+  * [http://www.emmss.com 网站建设]
 
 
Not sure what emmss.com is all about.


 diff -urN /tmp/wiki.23iQYm/wiki/text/helponactions /home/groups/d/dr/dri/wiki/text/helponactions
--- /tmp/wiki.23iQYm/wiki/text/helponactions	1969-12-31 16:00:00.0 -0800
+++ /home/groups/d/dr/dri/wiki/text/helponactions	2004-04-27 02:55:48.0 -0700
@@ -0,0 +1,13 @@
+Describe helponactions here.
+Sex pictures
+http://www.dilettantes.biz
+http://www.dilettantes.biz/amateur-sex.html
+Tranny sex
+http://www.tranny-movies.info
+Pregnant porn
+http://www.pregnant-porn.net
+http://www.sex-web-sites.net
+http://www.sexset.net
+Big boobs
+http://www.stripbabe.net
+http://www.pictures-of-sex.com 
Some dodgy stuff here...

Keith



---
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] RE: radeon t_vertex conversion

[Keith Whitwell]

Andreas Stenglein wrote:
here is a new snapshot for R100 based cards
(only for testing, isn't ready for merging)
It seems to work ok with most apps I tested,
but it doesn't work for yuvrect.
Do we need the _radeon_render_stage or
should the _tnl_render_stage be enough?
_radeon_render_stage is a faster path for unclipped vertex buffers.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] [PATCH] R200 t_vertex conversion

[Keith Whitwell]

Ian Romanick wrote:
Keith Whitwell wrote:

Keith Whitwell wrote:

Ian Romanick wrote:

Here's an updated version of the patch.  It incorporates most of 
Keith's code.  It seems to mostly work with 2 exceptions.

- r200PointsBitmap is still broken.  I'm not sure what the right way 
is going to be to fix that.

- Colors are wrong.  The cylinder in gloss is brownish instead of 
purple, and the red & blue gears in gears have their colors 
swapped.  It almost looks like the RGBA values are being sent to the 
card in the wrong order (i.e., as BGRA).


Yes, that's exactly what's happening.  The enums for RGBA & BGRA are 
flipped in t_vertex.h.  During testing with i830, I convinced myself 
that that hardware had RGBA vertices so I didn't notice the error.


Here's a patch with the corrected enums, and fixes to the i830 and 
savage driver to maintain their current behaviour.


Wonderful!  Could you commit the non-R200 parts while I finish up the 
r200PointsBitmap code?  I should be able to resolve that today.
OK, done.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] [PATCH] R200 t_vertex conversion

[Keith Whitwell]

Keith Whitwell wrote:
jIan Romanick wrote:

Here's an updated version of the patch.  It incorporates most of 
Keith's code.  It seems to mostly work with 2 exceptions.

- r200PointsBitmap is still broken.  I'm not sure what the right way 
is going to be to fix that.

- Colors are wrong.  The cylinder in gloss is brownish instead of 
purple, and the red & blue gears in gears have their colors swapped.  
It almost looks like the RGBA values are being sent to the card in the 
wrong order (i.e., as BGRA).

Yes, that's exactly what's happening.  The enums for RGBA & BGRA are 
flipped in t_vertex.h.  During testing with i830, I convinced myself 
that that hardware had RGBA vertices so I didn't notice the error.
Here's a patch with the corrected enums, and fixes to the i830 and savage 
driver to maintain their current behaviour.

Keith
Index: src/mesa/drivers/dri/r200/r200_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_context.h,v
retrieving revision 1.12
diff -u -r1.12 r200_context.h
--- a/src/mesa/drivers/dri/r200/r200_context.h  11 Mar 2004 20:35:40 -  1.12
+++ b/src/mesa/drivers/dri/r200/r200_context.h  21 Apr 2004 13:13:41 -
@@ -39,6 +39,7 @@
 #ifdef GLX_DIRECT_RENDERING
 
 #include 
+#include "tnl/t_vertex.h"
 #include "drm.h"
 #include "radeon_drm.h"
 #include "dri_util.h"
@@ -611,12 +612,12 @@
 /* r200_swtcl.c
  */
 struct r200_swtcl_info {
-   GLuint SetupIndex;
-   GLuint SetupNewInputs;
GLuint RenderIndex;
GLuint vertex_size;
-   GLuint vertex_stride_shift;
-   GLuint vertex_format;
+
+   struct tnl_attr_map vertex_attrs[VERT_ATTRIB_MAX];
+   GLuint vertex_attr_count;
+
GLubyte *verts;
 
/* Fallback rasterization functions
@@ -629,6 +630,18 @@
GLenum render_primitive;
GLuint numverts;
 
+   /**
+* Offset of the 4UB color data within a hardware (swtcl) vertex.
+*/
+   GLuint coloroffset;
+
+   /**
+* Offset of the 3UB specular color data within a hardware (swtcl) vertex.
+*/
+   GLuint specoffset;
+
+   GLboolean needproj;
+
struct r200_dma_region indexed_verts;
 };
 
Index: src/mesa/drivers/dri/r200/r200_swtcl.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c,v
retrieving revision 1.9
diff -u -r1.9 r200_swtcl.c
--- a/src/mesa/drivers/dri/r200/r200_swtcl.c20 Jan 2004 02:49:27 -  1.9
+++ b/src/mesa/drivers/dri/r200/r200_swtcl.c21 Apr 2004 13:13:41 -
@@ -56,323 +56,187 @@
 #include "r200_swtcl.h"
 #include "r200_tcl.h"
 
-/***
- *  Build render functions from dd templates   *
- ***/
-
-
-#define R200_XYZW_BIT  0x01
-#define R200_RGBA_BIT  0x02
-#define R200_SPEC_BIT  0x04
-#define R200_TEX0_BIT  0x08
-#define R200_TEX1_BIT  0x10
-#define R200_PTEX_BIT  0x20
-#define R200_MAX_SETUP 0x40
 
 static void flush_last_swtcl_prim( r200ContextPtr rmesa  );
 
-static struct {
-   void(*emit)( GLcontext *, GLuint, GLuint, void *, GLuint );
-   interp_func interp;
-   copy_pv_funccopy_pv;
-   GLboolean   (*check_tex_sizes)( GLcontext *ctx );
-   GLuint   vertex_size;
-   GLuint   vertex_format;
-} setup_tab[R200_MAX_SETUP];
-
-
-static int se_vtx_fmt_0[] = {
-   0,
-
-   (R200_VTX_XY |
-R200_VTX_Z0 |
-(R200_VTX_PK_RGBA << R200_VTX_COLOR_0_SHIFT)),
-
-   (R200_VTX_XY |
-R200_VTX_Z0 |
-R200_VTX_W0 |
-(R200_VTX_PK_RGBA << R200_VTX_COLOR_0_SHIFT) |
-(R200_VTX_PK_RGBA << R200_VTX_COLOR_1_SHIFT)),
-
-   (R200_VTX_XY |
-R200_VTX_Z0 |
-R200_VTX_W0 |
-(R200_VTX_PK_RGBA << R200_VTX_COLOR_0_SHIFT) |
-(R200_VTX_PK_RGBA << R200_VTX_COLOR_1_SHIFT)),
-
-   (R200_VTX_XY |
-R200_VTX_Z0 |
-R200_VTX_W0 |
-(R200_VTX_PK_RGBA << R200_VTX_COLOR_0_SHIFT) |
-(R200_VTX_PK_RGBA << R200_VTX_COLOR_1_SHIFT)),
-
-   (R200_VTX_XY |
-R200_VTX_Z0 |
-R200_VTX_W0 |
-(R200_VTX_PK_RGBA << R200_VTX_COLOR_0_SHIFT) |
-(R200_VTX_PK_RGBA << R200_VTX_COLOR_1_SHIFT))
-};
-
-static int se_vtx_fmt_1[] = {
-   0,
-   0,
-   0,
-   ((2 << R200_VTX_TEX0_COMP_CNT_SHIFT)),
-   ((2 << R200_VTX_TEX0_COMP_CNT_SHIFT) |
-(2 << R200_VTX_TEX1_COMP_CNT_SHIFT)),
-   ((3 << R200_VTX_TEX0_COMP_CNT_SHIFT) |
-(3 << R200_VTX_TEX1_COMP_CNT_SHIFT)),
-};
-
-#define TINY_VERTEX_FORMAT 1
-#define NOTEX_VERTEX_FORMAT2
-#define TEX0_VERTEX_FORMAT 3
-#define TEX1_VERTEX_FORMAT 4
-#define PROJ_TEX1_VERTEX_FORMAT5
-#define TEX2_VERTEX_FORMAT 0
-#define TEX3_VERTEX_FORMAT 0
-#de

Re: [Dri-devel] [PATCH] R200 t_vertex conversion

[Keith Whitwell]

jIan Romanick wrote:
Here's an updated version of the patch.  It incorporates most of Keith's 
code.  It seems to mostly work with 2 exceptions.

- r200PointsBitmap is still broken.  I'm not sure what the right way is 
going to be to fix that.

- Colors are wrong.  The cylinder in gloss is brownish instead of 
purple, and the red & blue gears in gears have their colors swapped.  It 
almost looks like the RGBA values are being sent to the card in the 
wrong order (i.e., as BGRA).

Yes, that's exactly what's happening.  The enums for RGBA & BGRA are flipped 
in t_vertex.h.  During testing with i830, I convinced myself that that 
hardware had RGBA vertices so I didn't notice the error.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRM pci ids

[Keith Whitwell]

I'm still waiting for the request to have both drivers handle interrupts. I'm
sure that will be fun to implement. The correct solution is to take the source
for FB and DRM, copy them to the same directory and edit until everything works
in a single driver. That single driver may end up shipping standard in 2.7 but
that doesn't mean we can't start building it today. That why I proposed making a
new DRM CVS over in mesa. The mesa version would be the 2.7 targeted one.
The way we do experimental development on all these projects is with branches. 
 We don't copy DRI cvs somewhere else when we want to start breaking stuff, 
DRM should be no different.  It's not as if we haven't acheived complex rework 
of code on branches in the past.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] [PATCH] R200 t_vertex conversion

[Keith Whitwell]

Felix Kühling wrote:
On Tue, 20 Apr 2004 10:46:36 -0700
Ian Romanick <[EMAIL PROTECTED]> wrote:
[snip]

Right now both your latest patch and my patch seem to be totally hosed. 
 I haven't changed any of my code since Friday (when it mostly worked), 
but there have been some changes since then in Mesa.  Anything that uses 
textures has major issues with my patch, but things that don't use 
textures seem to (still) be mostly okay.

Can someone verify that other drivers that use t_vertex still work okay 
with current Mesa?


I updated Mesa and DRI a few hours ago on my Laptop (Savage). I didn't
notice any regressions.
Yes, mesa seems fine, but somehow the patches are broken now.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] RE: radeon t_vertex conversion

[Keith Whitwell]

Andreas Stenglein wrote:
Am 2004.04.19 00:51:16 +0200 schrieb(en) Michel Dänzer:

On Mon, 2004-04-19 at 00:29, Andreas Stenglein wrote:

After setting tcl_mode to 0, glxgears and quake3 didnt work as expected.
glxgears looks like http://penguinppc.org/~daenzer/DRI/glxgears.png
here; if I press the cursor keys, the inner colour changes, but not the
geometry. Is this what you're seeing as well, or is this an architecture
specific problem?


it's almost the same here on x86: only the colors look a bit different.
red corners, blue ring, black middle
If you change the shape of the glxgears-window to "widescreen"
you will see something rotating.
any hints?

If you look at my (untested!) r200 patch, you'll see I've added stuff to 
calculate rmesa->swtcl.coloroffset and rmesa->swtcl.specoffset.  Those will 
probably help glxgears.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] RE: radeon t_vertex conversion

[Keith Whitwell]

Andreas Stenglein wrote:
sorry..

I missed to set tcl_mode=0,
so the programs were running in HW-TCL mode.
After setting tcl_mode to 0, glxgears and quake3 didnt work as expected.
Ah gack, my r200 changes haven't been tested for similar reasons...

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] [PATCH] R200 t_vertex conversion

[Keith Whitwell]

Keith Whitwell wrote:
Ian Romanick wrote:

This is what I have done so far to convert the R200 driver to use 
t_vertex.  It is only a conversion for SW TCL, and it's not quite 
complete.  I've managed to clean up all the crashes that I could find, 
but I've only tested with gears, geartrain, and tunnel.  There are 
some known problems:

- The textures in tunnel are not quite right.  They're sort of zig-zaggy.
- The colors of two of the gears in gears are swapped.  The red gear 
is blue and the blue gear is red.  The green gear is correct.

I chopped out all of the _r200_render_stage stuff from r200_swtcl.c.  
It is unused (due to bad interactions with UT2k3), and was only 
confusing me.  When this patch gets committed, that code can go back 
in, I think.

There are two hacks that I had to do to get things working.  Neither 
of these needed to be done by the i830 or savage drivers.  First, I 
had to add a "viewport" matrix that remains an identity matrix.  This 
is because the Radeon chips do the viewport transform in hardware. 
tnl_dd/t_dd_vbtmp.h had the ability to handle hardware like this, but 
t_vertex apparently does not.  Second, I had to force TNL to always 
produce project coordinates.  Again, the Radeon hardware can do the 
final projection in hardware almost all the time, but due to the way 
the i830 and savage drivers use use tnl->vb.NdcPtr (actually 
VB->NdcPtr) I couldn't see a way around this.  I may just be missing 
something there.


Ah, ok.  I see the problem.  Basically this has to do with the fact that 
choosing the hw vertex format has gone from being something (normally) 
done ahead of time, prior to actually running the tnl pipeline, to 
something done after that, and based on its results.  The only problem 
is that by this time, the pipeline has run, and it's too late to decide 
whether or not to calculate projected coordinates.  Oh well, it's not 
too hard to do that ahead of time.
Here's an updated patch.  In addition to the above, I've fixed up the way 
'coloroffset' and the previously hardwired 'specoffset' are initialized.  Most 
stuff seems to work ok now, except tuxracer-demo, which has issues which are 
probably related to polygon offset.

Keith
? diff
? drivers/dri/diff
? drivers/dri/common/diff
? drivers/dri/i830/diff
? drivers/dri/r200/diff
? drivers/dri/tdfx/diff
? tnl/backout
? tnl/c
? tnl/dead
? tnl/diff
? tnl_dd/diff
Index: drivers/dri/r200/r200_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_context.h,v
retrieving revision 1.12
diff -u -r1.12 r200_context.h
--- a/drivers/dri/r200/r200_context.h   11 Mar 2004 20:35:40 -  1.12
+++ b/drivers/dri/r200/r200_context.h   18 Apr 2004 12:13:36 -
@@ -39,6 +39,7 @@
 #ifdef GLX_DIRECT_RENDERING
 
 #include 
+#include "tnl/t_vertex.h"
 #include "drm.h"
 #include "radeon_drm.h"
 #include "dri_util.h"
@@ -611,12 +612,13 @@
 /* r200_swtcl.c
  */
 struct r200_swtcl_info {
-   GLuint SetupIndex;
-   GLuint SetupNewInputs;
GLuint RenderIndex;
GLuint vertex_size;
-   GLuint vertex_stride_shift;
-   GLuint vertex_format;
+
+   struct tnl_attr_map vertex_attrs[VERT_ATTRIB_MAX];
+   GLuint vertex_attr_count;
+
+
GLubyte *verts;
 
/* Fallback rasterization functions
@@ -629,6 +631,11 @@
GLenum render_primitive;
GLuint numverts;
 
+   GLboolean needproj;
+   
+   GLuint coloroffset;
+   GLuint specoffset;
+
struct r200_dma_region indexed_verts;
 };
 
Index: drivers/dri/r200/r200_swtcl.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c,v
retrieving revision 1.9
diff -u -r1.9 r200_swtcl.c
--- a/drivers/dri/r200/r200_swtcl.c 20 Jan 2004 02:49:27 -  1.9
+++ b/drivers/dri/r200/r200_swtcl.c 18 Apr 2004 12:13:37 -
@@ -56,323 +56,185 @@
 #include "r200_swtcl.h"
 #include "r200_tcl.h"
 
-/***
- *  Build render functions from dd templates   *
- ***/
-
-
-#define R200_XYZW_BIT  0x01
-#define R200_RGBA_BIT  0x02
-#define R200_SPEC_BIT  0x04
-#define R200_TEX0_BIT  0x08
-#define R200_TEX1_BIT  0x10
-#define R200_PTEX_BIT  0x20
-#define R200_MAX_SETUP 0x40
 
 static void flush_last_swtcl_prim( r200ContextPtr rmesa  );
 
-static struct {
-   void(*emit)( GLcontext *, GLuint, GLuint, void *, GLuint );
-   interp_func interp;
-   copy_pv_funccopy_pv;
-   GLboolean   (*check_tex_sizes)( GLcontext *ctx );
-   GLuint   vertex_size;
-   GLuint   vertex_format;
-} setup_tab[R200_MAX_SETUP];
-
-
-static int se_vtx_fmt_0[]

Re: [Dri-devel] [PATCH] R200 t_vertex conversion

[Keith Whitwell]

Ian Romanick wrote:
This is what I have done so far to convert the R200 driver to use 
t_vertex.  It is only a conversion for SW TCL, and it's not quite 
complete.  I've managed to clean up all the crashes that I could find, 
but I've only tested with gears, geartrain, and tunnel.  There are some 
known problems:

- The textures in tunnel are not quite right.  They're sort of zig-zaggy.
- The colors of two of the gears in gears are swapped.  The red gear is 
blue and the blue gear is red.  The green gear is correct.

I chopped out all of the _r200_render_stage stuff from r200_swtcl.c.  It 
is unused (due to bad interactions with UT2k3), and was only confusing 
me.  When this patch gets committed, that code can go back in, I think.

There are two hacks that I had to do to get things working.  Neither of 
these needed to be done by the i830 or savage drivers.  First, I had to 
add a "viewport" matrix that remains an identity matrix.  This is 
because the Radeon chips do the viewport transform in hardware. 
tnl_dd/t_dd_vbtmp.h had the ability to handle hardware like this, but 
t_vertex apparently does not.  Second, I had to force TNL to always 
produce project coordinates.  Again, the Radeon hardware can do the 
final projection in hardware almost all the time, but due to the way the 
i830 and savage drivers use use tnl->vb.NdcPtr (actually VB->NdcPtr) I 
couldn't see a way around this.  I may just be missing something there.
Ah, ok.  I see the problem.  Basically this has to do with the fact that 
choosing the hw vertex format has gone from being something (normally) done 
ahead of time, prior to actually running the tnl pipeline, to something done 
after that, and based on its results.  The only problem is that by this time, 
the pipeline has run, and it's too late to decide whether or not to calculate 
projected coordinates.  Oh well, it's not too hard to do that ahead of time.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] [PATCH] R200 t_vertex conversion

[Keith Whitwell]

Ian Romanick wrote:
This is what I have done so far to convert the R200 driver to use 
t_vertex.  It is only a conversion for SW TCL, and it's not quite 
complete.  I've managed to clean up all the crashes that I could find, 
but I've only tested with gears, geartrain, and tunnel.  There are some 
known problems:

- The textures in tunnel are not quite right.  They're sort of zig-zaggy.
- The colors of two of the gears in gears are swapped.  The red gear is 
blue and the blue gear is red.  The green gear is correct.

I chopped out all of the _r200_render_stage stuff from r200_swtcl.c.  It 
is unused (due to bad interactions with UT2k3), and was only confusing 
me.  When this patch gets committed, that code can go back in, I think.

There are two hacks that I had to do to get things working.  Neither of 
these needed to be done by the i830 or savage drivers.  First, I had to 
add a "viewport" matrix that remains an identity matrix.  This is 
because the Radeon chips do the viewport transform in hardware. 
tnl_dd/t_dd_vbtmp.h had the ability to handle hardware like this, but 
t_vertex apparently does not. 
Just specify that element as 'EMIT_4F' or 'EMIT_3F', rather than 
'EMIT_4F_VIEWPORT'.

Second, I had to force TNL to always 
produce project coordinates.  Again, the Radeon hardware can do the 
final projection in hardware almost all the time, but due to the way the 
i830 and savage drivers use use tnl->vb.NdcPtr (actually VB->NdcPtr) I 
couldn't see a way around this.  I may just be missing something there.

I do have one other question that probably only Keith or Daniel can 
answer. :)  Can t_vertex replace the immediate-mode API code-gen in the 
radeon and r200 drivers?  It seems like it should be able to, but I'm 
not sure I can see exactly how.  Does the HW TCL side just need a 
tnl_attr_map just like the SW TCL side?  I think looking at the SW TCL 
code for so long has fried my brain...
The immediate-mode codegen pretty much cuts out the tnl module altogether and 
builds hardware vertices directly.  The t_vertex.c code would be redundant in 
that case.  If you just mean using this logic to determine the vertex format, 
I suppose it's possible, but you'll run into differences between what is 
needed pre-TCL vs. what is being calculated here for vertices post-TCL.

In any case, I won't have a chance to look at this again in until 
probably next Wednesday.  If someone could pick this up and finish it 
off, that would be cool.  I think it's more important to get it done 
soon than have my name in the commit log. :)

-#define IND (R200_XYZW_BIT|R200_RGBA_BIT|R200_SPEC_BIT)
-#define TAG(x) x##_wgfs
-#include "tnl_dd/t_dd_vbtmp.h"
+#define EMIT_PAD( N )			\
+do {	\
+   rmesa->swtcl.vertex_attrs[rmesa->swtcl.vertex_attr_count].attrib = 0;		\
+   rmesa->swtcl.vertex_attrs[rmesa->swtcl.vertex_attr_count].format = EMIT_PAD;	\
+   rmesa->swtcl.vertex_attrs[rmesa->swtcl.vertex_attr_count].offset = (N);		\
+   rmesa->swtcl.vertex_attr_count++;	\
+} while (0)
 
-#define IND (R200_XYZW_BIT|R200_RGBA_BIT|R200_SPEC_BIT|\
-	 R200_TEX0_BIT)
-#define TAG(x) x##_wgfst0
-#include "tnl_dd/t_dd_vbtmp.h"
+static void r200SetVertexFormat( GLcontext *ctx )
+{
+   r200ContextPtr rmesa = R200_CONTEXT( ctx );
+   TNLcontext *tnl = TNL_CONTEXT(ctx);
+   struct vertex_buffer *VB = &tnl->vb;
+   GLuint index = tnl->render_inputs;
+   int fmt_0;
+   int fmt_1;
+   GLboolean is_tiny = GL_TRUE;
 
-#define IND (R200_XYZW_BIT|R200_RGBA_BIT|R200_SPEC_BIT|\
-	 R200_TEX0_BIT|R200_PTEX_BIT)
-#define TAG(x) x##_wgfspt0
-#include "tnl_dd/t_dd_vbtmp.h"
 
-#define IND (R200_XYZW_BIT|R200_RGBA_BIT|R200_SPEC_BIT|\
-	 R200_TEX0_BIT|R200_TEX1_BIT)
-#define TAG(x) x##_wgfst0t1
-#include "tnl_dd/t_dd_vbtmp.h"
+   /* Important:
+*/
+   VB->AttribPtr[VERT_ATTRIB_POS] = VB->NdcPtr;
+   assert( VB->NdcPtr != NULL );
+   rmesa->swtcl.vertex_attr_count = 0;
 
-#define IND (R200_XYZW_BIT|R200_RGBA_BIT|R200_SPEC_BIT|\
-	 R200_TEX0_BIT|R200_TEX1_BIT|R200_PTEX_BIT)
-#define TAG(x) x##_wgfspt0t1
-#include "tnl_dd/t_dd_vbtmp.h"
+   fmt_0 = R200_VTX_XY | R200_VTX_Z0;
+   fmt_1 = 0;
 
+   /* EMIT_ATTR's must be in order as they tell t_vertex.c how to
+* build up a hardware vertex.
+*/
+   if (index & (_TNL_BITS_TEX_ANY | _TNL_BIT_COLOR1 | _TNL_BIT_FOG)) {
+  EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_4F_VIEWPORT, R200_VTX_W0 );
+  is_tiny = GL_FALSE;
+   }
+   else {
+  EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_3F_VIEWPORT, 0 );
+   }
Here specifically -- if you don't want to do viewport transform in sw, don't 
tell t_vertex.c to EMIT_xF_VIEWPORT.

Also - I'm not sure why you feel that COLOR1 or FOG (vertex fog, right?) 
require the W coordinate, though certainly the old code did work that way, 
this new code will differ from the old code in other respects so why maintain 
this old limitiation?


-/***
- * Initialization 
- ***

Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading

[Keith Whitwell]

Nathanael Nerode wrote:
This is a diff for drivers/char/drm to make r128 use userland-loadable
firmware.  It's completely untested (since I don't *have* an r128, I don't
see any way to test it), but I bet it'll work; the firmware loading interface
seems remarkably easy to use.
Following that (in the form of a diff) is the short program I used to create
a microcode file which could be shipped as the file
/usr/lib/hotplug/r128_cce_microcode
(I left it in this form to avoid problems with attaching binaries.)
Similar (nearly identical) changes could be made to the radeon driver in
the same directory, and I'll be happy to make them if needed.
This could probably be improved by someone with a better sense of
the right way to deal with the stupid endianness issues; I went with the
simplistic "pick an endianness" choice.
Please do tell me if there's a major problem with this that I can fix.  The one
which worries me the most is the possibility that the firmware loading is
not done in user context, or that it's done when holding a lock which means
that it mustn't sleep.  (Request_firmware obviously sleeps, since it calls
into userland.)  After spending something like 6 hours trawling
through the code backwards and forwards, I decided it *probably* wasn't,
but I wasn't sure.
There's also a faint possibility of deadlock if the userland process which
is supposed to load the firmware waits for the DRM module in order to use
the screen; this shouldn't happen because it's a background daemon (hotplug),
and the standard script only calls "cat [file] > sysfs/[phony file]".
If either of these is a problem, the firmware may have to be loaded
and cached in memory at module load time in the module load routine, and only
disposed of at module unload.  I couldn't actually find those routines, which
is one reason I didn't do that.  ;-)  The other is that it seems like it's a
waste of memory to do anything other than retrieving it when it's needed and
disposing of it afterwards.
Of course, given my lack of DRM experience, there could be any number of
other gotchas.  :-P
My changes are GPL licensed (of course).
The r128 module is BSD licensed (though I thought it was supposed to be dual 
BSD/GPL) - are you willing to reconsider?  If not it will be hard to integrate 
your changes, regardless of their technical merit.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] code for supporting reset from DRM

[Keith Whitwell]

Jon Smirl wrote:
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:

As Alan pointed out on IRC, it won't. But providing the means to do it


I'm using code extracted from the reset function in Xfree.  It seems to work for
Xfree, why shouldn't it work for me?

cleanly is certainly good basically. The question is exactly where it
belongs. I suggested to do this work on a branch for the time being, and
got zero feedback. I don't know what that's supposed to mean; some
people take silence as approval, but I don't.


I have six months worth of code that I can't check in because it all relies on a
sequence of patches. I have so many patches I am getting confused and losing
code. I'm doing this work for fun, I'm not getting paid, and lately it hasn't
been too much fun. If changes to DRM are going to be blocked please tell me now
and I will go work on another project. 
My problem with your changes is that I really don't know how to evaluate them. 
   Secondly, there seem to be people who know what they're talking about who 
have real objections to some of them.

Perhaps you need to go back to your sequence of patches and identify those 
that can be merged individually as incremental improvements to the existing 
drm module, or perhaps even to new modules, and that are relatively 
"uncontroversial".

In general, I don't think that saying 'this is what MS is doing, hence we need 
to somehow compete' is going to swing people who care about the kernel & its 
structure.  You need to express your desired changes in terms of what 
technical problems are being solved and also accept that there might be other 
ways to address those problems.

I'm sure you're capable of doing this, but you need to understand that you may 
have looked very closely at some particular problem & others are maybe a step 
or two behind you - and may not even recognize something as a problem at this 
point.

There have been a lot of changes proposed & some real objections to some of 
them - I'd like to see those resolved somehow.  I'd also like to avoid what 
looks like a small issue of approach or style end up driving an active 
developer to some different project.

Keith





---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Makefiles in the drm module

[Keith Whitwell]

Michel DÃnzer wrote:
Does anything speak against repo-moving Makefile.{bsd,linux} to
Makefile?
I can't think of any reason not to.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRI mesa drivers bulding in mesa tree

[Keith Whitwell]

Jon Smirl wrote:
I've been gone for a few weeks, what's the current state of getting the the DRI
mesa drivers bulding in mesa tree? It seems to me like this would make the build
process much simpler.
Well, I've just committed a 'linux-dri' target which will build currently only 
the i830_dri.so module.

There's some interaction with 'linux-solo', of course, so if you wanted to 
look at this & make sure everything's ok, we can move towards getting the 
others building - which should be pretty simple.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] First dri.so built in Mesa tree

[Keith Whitwell]

OK, I can now build & run i830_dri.so from the Mesa tree using 'make linux-dri'.

It's a bit hacked together, but people who are interested should cast their 
eyes over:

configs/linux-dri
src/mesa/drivers/dri/Makefile.template
src/mesa/drivers/dri/dri_client/*
src/mesa/drivers/dri/i830/Makefile
There's not a lot to it, though there is something odd still going on with 
xf86drm.h and i830_dri.h

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [patch] Trying to get DRM up to date in 2.6

[Keith Whitwell]

Ian Romanick wrote:
Michel DÃnzer wrote:

Thanks again for your work on this Dave.

BTW, what's your (and everyone's, for that matter) opinion on
video-reset and the libsysfs copy being in the drm module? I still don't
see the point of the former being there, much less the latter.


I agree with Dave.  libsysfs should get the axe, but video-reset can 
stay or go.  I do think that libdrm should get moved to the drm tree. 
That will probably require move invasive changes to the build process, 
though.
When you say libdrm, I think of something tied to XFree86 & its module system 
in some basic way - if that was the case I'd object.  But I'm betting you're 
suggesting putting a nice clean userspace library for the various drm kernel 
modules in the drm tree, which makes a lot of sense.  Maybe the libdrm inside 
XFree86 already fits that description?

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Where dri parts reside now.

[Keith Whitwell]

Jacek Rosik wrote:
Hi,

For some time i haven't been paying much attention to dri development.
I'm need to do some work now but I'm little lost. From my little
investigation I presume that situation looks more less like this.
* 3d driver development was moved to mesa tree, bu it needs dri tree in
order to compile.
Correct, but will soon compile on its own.

* Drm was moved to it's own module and it's developed there not in old
place in xc module and not in dri/drm subdirectory in mesa tree.
And seems to have gotten a new lease of life as a result...  Dave's doing a 
great job from the look of things...

* DDX driver is still in xc module.

Is there a plan to make 3d driver compile without dri tree? If so is it
going to be completely removed?
Yes to the first question, but I'm not currently planning to remove the DRI 
tree in any hurry...

What about DDX driver and DRI extension? Is it going to be moved
somewhere? XOrg or freedesktop's xserver trees? Maybe both?
Because we haven't really answered this one yet.  At the moment, I think the 
DRI tree is a good place for this work, but that's going to be more up to 
those who are active in those areas, which I really am not so much any more 
(if ever...).

BTW: I have local mirror (CVSup) of dri's cvs repository but drm module
isn't there. I presume because it's not in 'dri' collection. If I'm
right, can somebody add it?
Can you give some instructions as to how that would work...  I don't really 
know anything about CVSup.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [Mesa3d-dev] DRI mesa drivers bulding in mesa tree

[Keith Whitwell]

Ian Romanick wrote:
Jon Smirl wrote:

I've been gone for a few weeks, what's the current state of getting 
the the DRI
mesa drivers bulding in mesa tree? It seems to me like this would make 
the build
process much simpler.


It has stalled, and that's my fault.  I should be able to get back to 
that tomorrow.  Once I get my stuff done, other folks can pick it up and 
finish it off.  We can talk about it more in the meeting today.
I've been stalled on this for a while too.

It seems to me that it would be pretty simple to get the DRI drivers in their 
current form building in Mesa.  In fact I had this working in the embedded 
branch yonks ago.

Perhaps we're making things too difficult by trying to go straight a single 
binary for dri and solo as the first step -- it seems to me that we need DRI 
binaries now, and as it's not hard, we should just go ahead and do it.

I've got most of this done in my repository.  I didn't attend the meeting last 
night, but will I be stepping on toes if I start committing bits & pieces of this?

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRI CVS with X.org

[Keith Whitwell]

ajax wrote:
I've successfully installed the various libraries and modules from DRI CVS on 
top of an X.org build, and it appears to work.  (No great surprise that 
they're binary compatible still, I suppose.)  Instructions are on the 
Building page on the wiki, along with suitably scary warning text; I probably 
missed something in the process so corrections are welcomed.

It strikes me that this is probably a good thing for the Long Slow Decoupling 
of DRI from the X server, and that the given X.org instructions ought to work 
for XFree86 users as well.  This is great, because it means a) users don't 
clobber their X libs and server binary when installing DRI CVS, and b) DRI 
doesn't need to be synced against some other X server tree nearly as much.  
Everyone wins.

To that end I'm working on a shell script that would automate this minimalist 
install process, along with some magic to make it play nicely with Gentoo's 
OpenGL switcher (and any other OS- or distro-specific hooks).  Any interest 
in seeing this committed to CVS?
I believe there's a 'scripts' module in DRI cvs which would be an appropriate 
place for this sort of thing.

I'm not sure from your description, but would this install script be more 
appropriate as an addition to the install we're using for the snapshots, 
rather than as a new script?

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] (03-04-2004) - present Problem with libdri.a in snapshots

[Keith Whitwell]

Ian Romanick wrote:
Craig Sowadski wrote:

I am getting the following error when trying to run any DRI/GL program 
using snapshots staring at with radeon-20040304-linux.i386.tar.bz2 
until present:

X Error of failed request:  BadValue (integer parameter out of range 
for operation)
 Major opcode of failed request:  144 (XFree86-DRI)
 Minor opcode of failed request:  5 ()
 Value in failed request:  0x49
 Serial number of failed request:  24
 Current serial number in output stream:  24

I have traced the problem to be the file libdri.a, and must be 
something to do with this patch:

http://dri.freedesktop.org/cgi-bin/cvsweb/dri/xc/xc/programs/Xserver/GL/dri/dri.c.diff?r1=1.50&r2=1.51 

Everything seems to work fine using the libdri.a from 03-03-2004 with 
the newest snapshot drivers.

Let me know if you would like any other information.


There we go!  That's why I haven't been able to reproduce the problem! 
Can either libglx.a and libGLcore.a please be added to the binary 
snapshots or libdri.a be removed?  I'm sure there is a reason, buy why 
are libdri.a and libdrm.a included at all?
I think earlier libdrm.a didn't export the generic ioctl wrapper (drmCommand), 
but had a dinky wrapper for each ioctl.

libdri.a, I can't remember, but there is a reason.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: [Mesa3d-dev] More problems with t_vtx_x86_gcc.S

[Keith Whitwell]

Ian Romanick wrote:
If the code in t_vtx_x86.c is not built, then t_vtx_x86_gcc.S must not 
be built either.  The code in the .S references symbols in the .c. 
That's why I put the #ifdef around all the code in the .S in version 
1.3.  I guess my cvs log message wasn't clear enough. :(  I'm fixing 
this in my tree, but a better fix is needed.  It's really hard to do any 
useful development in DRI or Mesa right now. :(
Frankly, I'm happy to see this not being built in DRI at all at present, if 
you'd rather take a big-stick approach to this.

Apologies to everyone once more for f*cking things up so completely.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] bug - execute permissions on data areas

[Keith Whitwell]

John Dennis wrote:
Hmm... I can't seem to find a working bugzilla for DRI, instead things
seem to be directed here. I just opened the following bug for xorg, it
fixes various pieces of code that need to set execute permission on data
memory. Some of these are in DRI and Mesa, it would be great if could
get these fixes "upstream". Full explanation in the bugzilla referenced.
http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=399

Quite topical as we're currently adding more code which does this.  I'll 
integrate your patch as part of this work.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: [Mesa3d-dev] Problem with t_vtx_x86_gcc.S in DRI build system

[Keith Whitwell]

Felix Kühling wrote:
Hi,

in the DRI build system t_vtx_x86_gcc.S ends up being compiled this
command:
gcc -c -o t_vtx_x86_gcc.o t_vtx_x86_gcc.S

The defined like -DUSE_X86_ASM are not there because they are defined as
CFLAGS which are not used for compiling assembler sources files. Because
of the conditional statement at the top of t_vtx_x86_gcc.S several
symbols are undefined in the resulting 3D drivers:
#if defined(USE_X86_ASM) && !defined(HAVE_NONSTANDARD_GLAPIENTRY)

Is this conditional really needed?
I guess it's not needed for compilation, but this code definitely won't work 
on those systems with a non-standard calling convention.  So, the test could 
be moved elsewhere if that helps.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: [Mesa3d-dev] Conflicting symbols between radeon/r200_vtxtmp_x86.o and t_vtx_x86_gcc.o

[Keith Whitwell]

Felix Kühling wrote:
Hi,

when linking the radeon and r200 drivers I get these errors:

radeon_vtxtmp_x86.o(.data+0x18c): In function `_x86_Vertex3fv':
: multiple definition of `_x86_Vertex3fv'
../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x80): first defined here
radeon_vtxtmp_x86.o(.data+0x1d3): In function `_x86_Attribute2f':
: multiple definition of `_x86_Vertex3fv_end'
../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0xc7): first defined here
radeon_vtxtmp_x86.o(.data+0x1e6): In function `_x86_Attribute2fv':
: multiple definition of `_x86_Attribute2fv'
../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x121): first defined here
radeon_vtxtmp_x86.o(.data+0x1fb): In function `_x86_Attribute3f':
: multiple definition of `_x86_Attribute2fv_end'
../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x136): first defined here
radeon_vtxtmp_x86.o(.data+0x219): In function `_x86_Attribute3fv':
: multiple definition of `_x86_Attribute3fv'
../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x136): first defined here
radeon_vtxtmp_x86.o(.data+0x237): In function `_x86_Color4ubv_ub':
: multiple definition of `_x86_Attribute3fv_end'
../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x154): first defined here
I have no idea how to fix this because I don't know how the tnl_vtxfmt
code is supposed to interact with the vtxfmt code in the radeon drivers.
Can someone please fix this or disable the tnl vtxfmt code until this
has been sorted out?
I'll rename those symbols to avoid the conflict.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] [PATCH] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

[Keith Whitwell]

ajax wrote:
On Tuesday 30 March 2004 16:52, Brian Paul wrote:

CVSROOT:/cvs/mesa
Module name:Mesa
Repository: Mesa/src/mesa/main/
Changes by: [EMAIL PROTECTED]   04/03/30 14:52:00
Log message:
 these files now live in the shader directory
Removed files:
 Mesa/src/mesa/main/:
   nvfragparse.c nvfragparse.h nvfragprog.h nvprogram.c
   nvprogram.h nvvertexec.c nvvertexec.h nvvertparse.c
   nvvertparse.h nvvertprog.h


This breaks the DRI build:

s_aatriangle.c:37:24: nvfragprog.h: No such file or directory

Patch attached, which adds src/mesa/shader everywhere it's needed.  This is a 
bit heavy-handed; would it be better to factor $MESA_INCLUDES up to a higher 
Imakefile?
I've committed most of this (where it didn't clash with changes I've already 
made).

The build seems to work for me now, here.  Let me know what happens on your end.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa reshuffling breaks DRI compile

[Keith Whitwell]

Goyo Roth wrote:
Keith Whitwell wrote:

Goyo Roth wrote:

Mesa has moved some files around. Notably the arb* files that used to 
reside in src/mesa/main.  They have all been moved to src/mesa/shader 
and the arbparse* files have been renamed as well. It's a simple 
Imakefile update I think. Additional caveats are the grammar.h 
grammar_mesa.h and grammar_syn.h files found in src/mesa/shader which 
these moved files now include and depend on. I added them to my 
Imakefile.inc file as well.

Would you like to post a patch to fix the problems?

Keith

I'd be happy to, but I have not yet resolved all the problems to get a 
clean compile. It seems that Mesa also added struct dynfn to t_context.h 
which is included by t_pipeline.h which is included before 
r200_context.h in r200_context.c. r200_context.h also defines struct 
dynfn,  causing an error. This is all Mesa code though.  Code I don't 
understand too well just yet at that so I don't really know what the 
correct solution is since I don't know what the intention of adding this 
new struct dynfn declaration was in the first place.  Eliminating the 
definition in r200_context.h and #including "tnl/t_context.h" gets past 
the problem, but I don't know if it really is the right solution.

This is, perhaps, an issue to bring up with the Mesa developers?
Hmm.  Those new breakages were my fault... Sorry about that.  It looks like 
Ian has committed some changes to address my breakage - can you try again & see?

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa reshuffling breaks DRI compile

[Keith Whitwell]

Goyo Roth wrote:
Mesa has moved some files around. Notably the arb* files that used to 
reside in src/mesa/main.  They have all been moved to src/mesa/shader 
and the arbparse* files have been renamed as well. It's a simple 
Imakefile update I think. Additional caveats are the grammar.h 
grammar_mesa.h and grammar_syn.h files found in src/mesa/shader which 
these moved files now include and depend on. I added them to my 
Imakefile.inc file as well.

Would you like to post a patch to fix the problems?

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] A question on DRI and performance...

[Keith Whitwell]

Adam K Kirchhoff wrote:
There's a discussion currently on the rage3d.com linux forum as to whether
or not the DRI is good enough for 3D gaming.  One particular individual
has claimed that the reason why the FireGL drivers (which use the DRI)
have worse performance than the nVidia drivrs are because the FireGL
drivers use the DRI.  He argues that since the DRI 3D drivers implement as
much of the 3D pipeline as possible in userspace, and the nVidia driver
presumably implements more in kernel space (due to their 2 MB kernel
module size), the DRI has a lot more expensive context switches.
I know very little about video driver programming, so I'm curious if
anyone who can is willing to comment and possibly refute his claims?
The dri makes no specification where you put anything.  I doubt very much that 
nvidia has any significant part of the pipeline in kernel space.  That's what 
the videocard is for.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: Uninitialized variable 'size' used in r200TryReadPixels()

[Keith Whitwell]

Mike A. Harris wrote:
On Fri, 26 Mar 2004, Mike A. Harris wrote:


In XFree86 4.3.0, and also in current X.org X11, in the file:

	xc/lib/GL/mesa/src/drv/r200/r200_pixel.c

[SNIP]

I'm unfamiliar with this particular code, however it seems that 
the same calculation being done in r200TryDrawPixels() would be 
valid for r200TryReadPixels().

Does the patch I've attached look correct?


Of course, 30 seconds after sending my email, I noticed that the 
check_color() function does not even use the "sz" parameter it is 
passed anywhere.  Should check_color() just have that parameter 
removed, and all locations that use it updated to not pass that?
Yes, that would be best.  The size parameter looks like it can be removed from 
clip_pixelrect() function as well, as it never ends up getting used.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI

[Keith Whitwell]

Brian Paul wrote:
You don't have to copy from the back buffer to the front buffer until 
glFlush() or glFinish() are called.  That's assuming that 
glReadBuffer(GL_FRONT); glReadPixels(...) grabs pixels from the back 
color buffer.  If that's not true, you'd have to do the buffer copy 
before each glReadPixels().
Thats a reasonable optimization, but the basic technique is flawed -- it's 
probably possible to get the correct behaviour of a single-buffered visual in 
this way, but it's not going to be compliant at all for a double-buffered 
visual where the app is switching between drawing to the front & back buffers.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [Dri-users] Problems with savage and DRI

[Keith Whitwell]

Felix Kühling wrote:
Hi Marcin,

Also CCing to Alex, he probably knows more about this.

Currently the driver looks like it's not supposed to render to the front
buffer at all. When single buffering is used, the driver draws to the
back buffer and copies it over to the front buffer after processing a
Mesa vertex buffer. I have no idea if this is GL compliant.
No, it's not.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Via drm driver thoughts

[Keith Whitwell]

Thomas Hellstrom wrote:
Hi!

I've now implemented the DRM os-abstraction macros from drm_os_linux.h 
throughout the driver and, from what I can see, there is no linux 
specific stuff left.
My idea is therefore to check in the driver under "shared", but update 
only the linux makefiles until *BSD compatibility can be tested.

Would you like me to create a separate branch for this stuff or go 
directly for the trunk?
Unless you expect this to break one of the existing modules (which seems 
unlikely), I'm happy to see it go straight to the trunk.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Switching dri over to new drm tree

[Keith Whitwell]

ajax wrote:

> ... The i810 error is not a build failure but a
runtime failure with glxgears:



X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  144 (XFree86-DRI)
  Minor opcode of failed request:  5 ()
  Value in failed request:  0x1e2
  Serial number of failed request:  30
  Current serial number in output stream:  30

This was installed from a snapshot.  Snapshots up to March 2 worked, anything 
after that did not have working direct rendering.  But since the snaps are 
generated from the head...  I've seen this error posted here before but I 
haven't seen a resolution, maybe I missed it.
Ian, does this look at all like it could be related to your libGL, etc. changes?

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Switching dri over to new drm tree

[Keith Whitwell]

ajax wrote:
On Friday 19 March 2004 12:26, Brian Paul wrote:

I figured people doing driver development would prefer to work on a
stable Mesa branch, but it hasn't panned out that way.  I guess I
don't feel too strongly either way.
I don't think anyone's checked in any DRI driver changes to the stable
mesa_6_0_branch branch so I'm not sure what state it's in.
-Brian


Well right now HEAD doesn't work for at least i810 and probably some others.  
Hmm - it should.  If we're going to build against the stable Mesa branch, that 
should be done from a DRI branch as currently, DRI HEAD and Mesa HEAD are 
supposed to be in sync.  Currently the only way to build the DRI drivers in 
Mesa is from a DRI tree (though we're in the process of changing this).

Until there is a definite change of policy to build DRI head off some Mesa 
branch (or more likely to import a snapshot of a branch into xc/extras/Mesa), 
please report build failures as such in preference to telling people to build 
in a way that we can't support in an ongoing fashion (as Mesa HEAD and stable 
diverge).

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Via DRM module

[Keith Whitwell]

Alex Deucher wrote:

Hi!

I've now checked out the new cvs drm module and the via patch I sent
previously applies cleanly with
patch -p1
in drm/linux.
Also compiles cleanly under both 2.4 and 2.6


Is anyone averse to giving Thomas cvs commit access?
No.  Let's pester Daniel again...

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Switching dri over to new drm tree

[Keith Whitwell]

ajax wrote:
On Wednesday 17 March 2004 14:06, ajax wrote:


No problem.  I split the branches into current, sleeping, merged, and
obsolete, and added a note about the DRM changes.  I'll be adding more to
that list shortly.


Added a few to the list, mostly things I've had trouble with while getting 
tdfx to work again.


In the future, if a change to the trunk requires changes in a current or
sleeping branch, it should get a link on that list.  Of course ideally we'd
have no sleeping branches...


Which reminds me.  Brian, you'd said in:

http://marc.theaimsgroup.com/?l=dri-devel&m=107099482602285&w=2

that DRI builds should happen against a tagged Mesa branch.  Currently the 
Building page tells people to build against HEAD.  I know that's not good, 
but is that branch still the officially-blessed branch for stable builds?
For the meantime, yes.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Via DRM module

[Keith Whitwell]

Thomas Hellstrom wrote:
Hi!

Here comes the via drm module patch against current (at least as of 
today :-) CVS 
(/usr/local/src/dri-cvs/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm) 

What we've done is the following:
1. Base. Via:s drm Module 0038.
2. Added vblank_wait  IOCTL support (Terry Barnaby), via_irq.c
3. Added some XvMC specific locks in the private SAREA structure.
4. Added some copyright notes where it was obvious that Via had copied 
other drm code. (most notably sis_ds.h and sis_ds.c). Via has copied in 
a standard license header in all files, regardless of origin, so please 
yell if you feel that there should be attribution and / or copyright 
notices which are not there.
5. Changed the via_ds.h and via_ds.c external names to start with via, 
since the files and names were more or less identical to those of the 
sis driver. From what I can see there are no external names not starting 
with via at this point.
6. Updated it with version number, version date and PCI_ID's.

I've tried compiling it and run glxgears in its current form (Kernel 
2.6.1) and it works nicely.

Should you think it's OK, we could take a maintainer role of the via 
kernel module should no one else step forward.

This sounds good.

The slight fly in the ointment regarding applying this patch right now is the 
current state of flux in the drm code, which is being moved to sit in its own 
CVS module in the dri project.  To get the code in it's new location, checkout 
the "drm" module in DRI CVS.

I'd like to get reports back that the new code is compiling & working for 
people before dumping any big patches on it.  But it would be helpful if the 
patch were to apply directly to that tree rather than the old layout.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Via DRM module

[Keith Whitwell]

Thomas Hellstrom wrote:
Hi!

Here comes the via drm module patch against current (at least as of 
today :-) CVS 
(/usr/local/src/dri-cvs/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm) 

What we've done is the following:
1. Base. Via:s drm Module 0038.
2. Added vblank_wait  IOCTL support (Terry Barnaby), via_irq.c
3. Added some XvMC specific locks in the private SAREA structure.
4. Added some copyright notes where it was obvious that Via had copied 
other drm code. (most notably sis_ds.h and sis_ds.c). Via has copied in 
a standard license header in all files, regardless of origin, so please 
yell if you feel that there should be attribution and / or copyright 
notices which are not there.
5. Changed the via_ds.h and via_ds.c external names to start with via, 
since the files and names were more or less identical to those of the 
sis driver. From what I can see there are no external names not starting 
with via at this point.
6. Updated it with version number, version date and PCI_ID's.

I've tried compiling it and run glxgears in its current form (Kernel 
2.6.1) and it works nicely.

Should you think it's OK, we could take a maintainer role of the via 
kernel module should no one else step forward.

Regards.
/Thomas




















---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Switching dri over to new drm tree

[Keith Whitwell]

ajax wrote:
On Wednesday 17 March 2004 05:12, Felix Kühling wrote:


dri branches will also need to apply this patch
I don't like that. Can branches still keep their own copy of the old
DRM? I'm particulary thinking of the s3virge branch which is
unmaintained at the moment. I'm not sure if it even builds, but if it
does it would be nice to keep it that way until someone picks it up.


I just checked.  It doesn't.

make[6]: *** No rule to make target `../shared/at_scancode.c', needed by 
`at_scancode.c'.  Stop.

etc.

However, Jon has done the right thing by saying "this is what branches need to 
do to get working again".  They shouldn't need to patch _now_, but knowing 
what needs to be done in the future makes it possible to revive sleeping 
branches.

I think CVSBranches on the wiki needs to be reorganized into several sections 
(current, sleeping, and obsolete) to reflect this; current would stay about 
the same, sleeping would be things like savage and s3virge, and obsolete 
would be merged branches (r200) or abandoned branches (dmx, smt).  The 
sleeping ones could be annotated with links to mailing list posts describing 
the major changes.

If that sounds acceptable, let me know so I can rework CVSBranches.
This seems reasonable to me...  Thanks for taking this on.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Building DRI in Mesa tree

[Keith Whitwell]

Ian Romanick wrote:
Keith Whitwell wrote:

Ian Romanick wrote:

There also seem to be some issues with drivers using CARD32.  That 
type comes from X, so it should probably be replaced with something 
window-system agnostic.  Would int32_t work for everyone?


I think this is the best we can do, though at least some versions of 
FreeBSD had trouble with these types.  If need be we can add a 
conditional definition of this type in a header somewhere.


The BSDs had trouble with the 64-bit types in inttypes.h.  For the most 
part, the sized integer types in inttypes.h grew out of existing types 
in BSD. :)  int32_t and u_int32_t are old skool in BSD. ;)  In C99 
u_int32_t became uint32_t.  I encountered a similar problem with CARD8. 
 I don't recall if there's an analog for int8_t in older BSDs.  Later 
today (hopefully) I'll convert at least the R200 driver to use only the 
inttypes.h types.  I'll wait a few days to see if that breaks any of the 
BSDs before moving forward.

Another question.  dri_util.[ch] will need to be moved from DRI CVS to 
Mesa CVS.  Is it possible to copy the ,v files from one project to another?
Should be fine.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Switching dri over to new drm tree

[Keith Whitwell]

Michel DÃnzer wrote:
On Wed, 2004-03-17 at 10:14, Keith Whitwell wrote:

Jon Smirl wrote:

This patch switches the dri build over to use the new standalone drm tree.

You will need to check out the new drm tree from the dri CVS root
Apply the patch to dri
DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the
drm tree
You will also need to fix MesaSrcDir
make World 

dri branches will also need to apply this patch


Why? What happens on the trunk shouldn't affect them. That's the point
of a branch. :)


Checkout still fails:


[...]

Same here.



After the switch I can remove these directories from dri:
/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel
/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel
/xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel
Delete these locally if you want to make sure the patch is working
We want to make sure it is still relatively easy for XFree86 to pull in new 
versions of the DRM.  If we're making a shellscript to translate our files 
into the kernel's structure, maybe one to do the same job for XFree86 is sensible.


I'm inclined to consider this their problem...
Hmm.

It doesn't cost us anything to tie up loose ends.  We've effectively done this 
with the Mesa drivers - kept a working build system in the DRI tree so that a 
Mesa+Drivers living in extras/ can be linked and built in an XFree86 tree. 
Doing the same thing for DRM is an easy step we should take so that this has a 
fighting chance of getting into XFree86 CVS.

If you're going to argue that XFree86 CVS is suddenly not relevent, I'd 
counter that some fork or other offshoot of that codebase is or will become 
relevent, so the same argument applies.

For the meantime, I'd like to keep the DRI tree buildable with a Mesa/ and now 
DRM/ tree hanging around as crutches.

In the future, when we can build DRI drivers out of the Mesa tree, I'd still 
like to see us export releases from Mesa (eg. 6.0.1? or 6.1?) into the DRI 
tree extras/ directory and bring the build system uptodate at that point.

Eventually, if/when we are doing *NO* development in what's left of DRI CVS, 
then sure, let's let it die.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Building DRI in Mesa tree

[Keith Whitwell]

Ian Romanick wrote:
I spent some time today pulling the DRI interface structures and 
function prototypes out of glxclient.h.  I came across one snag that I 
missed before.  It turns out that the bindContext2 and unbindContext2 
methods in __DRIcontextRec are passed pointers to GLXContext structures. 
 I don't think that is the right division.  unbindContext2 only uses the 
GLXContext to get a pointer to the __DRIcontextRec.  bindContext2 does 
the same, but it also uses the GLXContext to get the __GLcontextModes 
structure for the context (when DRI_NEW_INTERFACE_ONLY is defined).

It should only take a little work to remove the usage of 'gc->modes'. 
When that is done, bindContext2 and unbindContext2 could be passed a 
pointer to the __DRIcontextRec.  I think this is the right thing to do.

The only problem is that it would break binary compatibility with 
XFree86 4.4.0. :(  So, it looks like I get to add yet another 
entry-point to __DRIcontextRec because I couldn't get things right the 
Nth time. :(

There also seem to be some issues with drivers using CARD32.  That type 
comes from X, so it should probably be replaced with something 
window-system agnostic.  Would int32_t work for everyone?
I think this is the best we can do, though at least some versions of FreeBSD 
had trouble with these types.  If need be we can add a conditional definition 
of this type in a header somewhere.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Switching dri over to new drm tree

[Keith Whitwell]

Jon Smirl wrote:
This patch switches the dri build over to use the new standalone drm tree.

You will need to check out the new drm tree from the dri CVS root
Apply the patch to dri
DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the
drm tree
You will also need to fix MesaSrcDir
make World 

dri branches will also need to apply this patch


Checkout still fails:

[EMAIL PROTECTED] xc-trunk]$ cvs checkout drm
cvs checkout: Updating drm
cvs checkout: Updating drm/bsd
U drm/bsd/Imakefile
U drm/bsd/Makefile.bsd
U drm/bsd/ati_pcigart.h
U drm/bsd/drmP.h
U drm/bsd/drm_agpsupport.h
U drm/bsd/drm_auth.h
U drm/bsd/drm_bufs.h
U drm/bsd/drm_context.h
U drm/bsd/drm_dma.h
U drm/bsd/drm_drawable.h
U drm/bsd/drm_drv.h
U drm/bsd/drm_fops.h
U drm/bsd/drm_ioctl.h
U drm/bsd/drm_irq.h
U drm/bsd/drm_lock.h
U drm/bsd/drm_memory.h
U drm/bsd/drm_memory_debug.h
U drm/bsd/drm_os_freebsd.h
U drm/bsd/drm_os_netbsd.h
U drm/bsd/drm_pci.h
U drm/bsd/drm_scatter.h
U drm/bsd/drm_sysctl.h
U drm/bsd/drm_vm.h
U drm/bsd/mga_drv.c
U drm/bsd/r128_drv.c
U drm/bsd/radeon_drv.c
U drm/bsd/sis_drv.c
U drm/bsd/tdfx_drv.c
cvs checkout: Updating drm/bsd/drm
cvs checkout: failed to create lock directory for `/cvs/dri/drm/bsd/drm' 
(/cvs/dri/drm/bsd/drm/#cvs.lock): Permission denied
cvs checkout: failed to obtain dir lock in repository `/cvs/dri/drm/bsd/drm'
cvs [checkout aborted]: read lock failed - giving up


I tried to patch up the bsd build but I don't run bsd so could someone please
check it.
Give me feedback and I can adjust the drm directory structure or the patch. When
everyone likes the new setup I will commit the patch. It will only take a minute
to do the switch over, I'll recopy the drm CVS v files when switching to pick up
any new checkins.
After the switch I can remove these directories from dri:
/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel
/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel
/xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel
Delete these locally if you want to make sure the patch is working
We want to make sure it is still relatively easy for XFree86 to pull in new 
versions of the DRM.  If we're making a shellscript to translate our files 
into the kernel's structure, maybe one to do the same job for XFree86 is sensible.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Getting the via drm module into CVS.

[Keith Whitwell]

Alex Deucher wrote:
--- Thomas Hellstrom <[EMAIL PROTECTED]> wrote:

Hi!

Via have, some time ago, released a drm module which seems quite
clean 
and a dri / OpenGL implementation which Alan Cox fixed up some time
ago 
and which is downloadable from your site. I don't think it has been 
ported to be compatible with dri CVS though.

The thing with the drm module seems to be another story. A lot of
people 
are patching their kernels with Via's source and are using it
together 
with Via's precompiled via_dri.so.

Also there is an ongoing project, (unichrome at sourceforge) the goal
of 
which is to develop and try to fix up the via X drivers, and submit 
relevant patches to the proper code maintainers. Currently we are 
focusing on the via XFree86 driver, and an XvMC extension for the HW 
Mpeg2 decoder (Which uses DRI /  DRM for register / memory mapping
and 
resource locking). But some small changes have been made also to the
Via 
drm driver (Wait on vblank support).

At this point it would be very nice to have the via drm module in dri

CVS, so that it could eventually be included in the kernel. While the

via_dri.so OpenGL driver might not be there yet, the drm module might
be.
Please advice on how to proceed and what is needed to make this
happen.


Erdi Chen maintains the cle266/unichrome 3D driver in mesa cvs.  You
should probably talk to him regarding changes to the 3D driver.  For
the 2D driver and DRM, no one has yet stepped up to put the latest code
in DRI cvs.  If you would like to maintain the via driver in DRI cvs, I
think you should be able to get cvs access to the DRI/mesa trees so you
can get your code in.  What do the other DRI develpers think?  It would
be nice to have the full suite of 3D capable cards with DRI support
available in the DRI.
Yes, there's certainly no need for splinter projects.  If you're doing work on 
DRI or Mesa, let us know who's active & we can get them access.  It's ususally 
nice to see some patches first, but if there's an active project elsewhere 
that we can check out & get a feel for, we might be able to skip that step.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRM in a standalone tree

[Keith Whitwell]

Daniel Stone wrote:
On Mon, Mar 15, 2004 at 07:24:50PM +, Keith Whitwell wrote:

Jon Smirl wrote:

Could someone with admin privs at fd.o please make a new project and put 
the two
DRM directories into it? It is probably easier to get them from
Mesa/src/mesa/drivers/dri/drm since the two directories are isolated there.
Right now the mesa and dri versions are identical so it doesn't matter.

If you would rather get them from the DRI tree you need:
dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel
dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel
As soon as this is done I will alter the mesa build process to use a 
pointer to
the new tree. That will allow us to keep everything building off from a 
single
copy of the h files preventing them from getting out of sync. After I get 
the
pointer working I'll remove the copy from mesa.
Just CC'ing Daniel Stone, the all-purpose fd.o admin guy & apparent 
melbournite.


Sure, I'll take that one. Do you want the project name to be 'mesadrm',
or what?
Actually, looks like this was a little premature.  We've probably got a few 
days of discussion before we even know what this thing will look like.  And as 
a first step we'll just create a new module in one of the existing projects, 
so no need to create a new project any time soon.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRM in a standalone tree

[Keith Whitwell]

Jon Smirl wrote:
Could someone with admin privs at fd.o please make a new project and put the two
DRM directories into it? It is probably easier to get them from
Mesa/src/mesa/drivers/dri/drm since the two directories are isolated there.
Right now the mesa and dri versions are identical so it doesn't matter.
If you would rather get them from the DRI tree you need:
dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel
dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel
As soon as this is done I will alter the mesa build process to use a pointer to
the new tree. That will allow us to keep everything building off from a single
copy of the h files preventing them from getting out of sync. After I get the
pointer working I'll remove the copy from mesa.
Just CC'ing Daniel Stone, the all-purpose fd.o admin guy & apparent melbournite.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: Three proposed new generic DRM IOCTLs

[Keith Whitwell]

Michel DÃnzer wrote:
On Sun, 2004-03-14 at 07:14, Jon Smirl wrote:

This is a first pass at the three new IOCTL patch.

It is against the DRM copy in the Mesa tree. 


And exactly why does that still exist? I know you don't listen to me,
but I don't think you can ignore Keith.
If there's any reason for this remaining, I'd like to hear it.  Keeping the 
headers is justifiable, I guess, but I don't want to see the DRM drivers 
living in two places.

If there's an argument that it's time to start a new tree for the DRM code to 
live in, I'm happy to progress in that direction.

In general, having one client of the drm "blessed" with the duty of holding 
the DRM code gives a skewed approach to the design of those modules.  Having 
them become a first-class project with their own tree & hopefully their own, 
concerned, developers looks like a more rational way forward.

So, I guess that's a vote from me for a new tree.  But certainly I don't want 
to see the guts of the DRM jump into the Mesa tree.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: [Mesa3d-dev] miniglx and DDX version checking

[Keith Whitwell]

Jon Smirl wrote:
I don't think they are necessary so the _SOLO defines could be extended. Keith
wrote the code  so I'm not sure what he intentions were.
--- Dave Airlie <[EMAIL PROTECTED]> wrote:

The current miniglx fakes up some DDX version numbers but these only work
for the radeon drivers, (4.0) is used, but the i810 drivers is only on
version 1.0,
Is there any need for this to be checked at all should the _SOLO defines
in utils.c:driCheckDriDdxDrmVersions be extended to cover the DDX check?
There's no need to check the faked up numbers.  Feel free to patch them out of 
existence, if possible.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: [Mesa3d-dev] Re: removing redundant SAREA/IOCTL defines

[Keith Whitwell]

Michel DÃnzer wrote:
On Fri, 2004-03-12 at 11:25, Dave Airlie wrote:

It shouldn't be very hard to do this for:
sis, tdfx, i810, i830, savage, gamma
so are we making the Mesa tree the DRM master repo as opposed to the DRI
tree? I don't remember much discussion on this either way,


Indeed, and I don't particularly like the idea.
My preference was always for it to live in a tree of its own.  That does leave 
the question of how you get at the headers in dependent projects.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: BK for X11 development? (was Re: [Dri-devel] Re: Status of XFree86 4.4.0 integration?)

[Keith Whitwell]

Andy Isaacson wrote:
On Mon, Mar 08, 2004 at 12:29:05PM -0800, Keith Packard wrote:

Stablizing the tree and getting something shipping that people can 
distribute is the first priority.  I'm sure lots of people would like to 
see Mesa/DRI development more closely tied to X driver development so that 
there wasn't this 'big merge' problem to face every few months.  

Precisely how that should work is something we can figure out in time.  One
key is to split responsibilities across stable interfaces so that we can
ship modern drivers into existing distributions.


I feel a little bit like a shill here, but I figure I should throw out
my two cents.  First, a disclaimer:  I work for BitMover but I do not set
company policy; if you need to get The Official Word on things regarding
BitMover or BK, you should talk to <[EMAIL PROTECTED]>.
For DRI at least, it's been discussed & rejected.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: Status of XFree86 4.4.0 integration?

[Keith Whitwell]

Mike A. Harris wrote:
On Mon, 1 Mar 2004, Alan Cox wrote:


On Llu, 2004-03-01 at 16:28, Michel DÃnzer wrote:

For my part, I'd certainly prefer staying clear of the silly new
license. In the long run, I'd vote for moving the DRI X server code to a
freedesktop.org X server tree and the libGL code to Mesa or its own
xlibs module.
I'd definitely like to see this, and perhaps closer CVS integration so
that DRI work can be done as a branch on the x.org tree not in a
seperate tree. Assuming all the relevant powers that be can make it
happen anyway


Yeah, I agree with that also.  The X.org tree aims to be a much 
more open community project.  The recent reformation of X.org 
into "The X.org Foundation" has brought with it a change in the 
governance structure, and there are new intirim board members 
present which make up a good cross section of the community 
projects which use X technology as a base to build upon.

The current plan is to have the tree develop in a way that is 
rather very similar to the DRI project's tree.  In fact, I am 
proposing that we adopt the DRI CVS guidelines in the X.org tree, 
and the rather liberal CVS access.  There's more to it than that 
as well, but all things aren't all worked out quite yet.

I believe that once the X.org tree is "off the ground" so to 
speak, that it would make sense to discuss the possibilities of 
merging the trees at some point.  I think it would be infinitely 
beneficial for both projects to have closer integration for 
numerous reasons, and would foster closer collaboration, 
between the DRI and the core, since the two owuld essentially 
become one and the same.

It is probably a bit premature for now to make any solid 
decisions though, but in the next few weeks/months things should 
take shape.
I don't have any in-principle objections to this, though I'd like to get more 
of a feel for the "new X.org" before committing to anything...   Will the 
X.org tree include all the XFree86 DDX code - we obviously rely on that as 
well as the core DRI protocol stuff.

Keith



---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: Wiki Update

[Keith Whitwell]

Keith Whitwell wrote:
Lots of junk & trash talk in here...
I see Michel spotted this yesterday.  I'm not really clued up enough on wiki's 
to know how to revert the edits, but it looks like they're still there.

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: Wiki Update

[Keith Whitwell]

Lots of junk & trash talk in here...

Keith

[EMAIL PROTECTED] wrote:
diff -urN /tmp/wiki.zQSGlf/wiki/text/BadGuy /home/groups/d/dr/dri/wiki/text/BadGuy
--- /tmp/wiki.zQSGlf/wiki/text/BadGuy	1969-12-31 16:00:00.0 -0800
+++ /home/groups/d/dr/dri/wiki/text/BadGuy	2004-02-26 09:11:42.0 -0800
@@ -0,0 +1,3 @@
+Large ugly penis, smells of dead fish and has a fetish for lor3's feet
+
+Hmz that explains why your breath smells of dead fish!
diff -urN /tmp/wiki.zQSGlf/wiki/text/Building /home/groups/d/dr/dri/wiki/text/Building
--- /tmp/wiki.zQSGlf/wiki/text/Building	2004-02-10 08:54:18.0 -0800
+++ /home/groups/d/dr/dri/wiki/text/Building	2004-02-26 06:45:36.0 -0800
@@ -31,6 +31,13 @@
 
 #define MesaSrcDir /path/to/Mesa
 
+NOTE:  If you are building cvs for savage, make sure to add savage to the 'XF86CardDrivers' and 'DriDrivers' defines.
+e.g.,
+
+#define XF86CardDrivers tdfx i810 mga ati glint vga sis savage
+
+#define DriDrivers r200 mga i810 r128 radeon gamma i830 sis tdfx ffb savage
+
  
 To build the whole thing, change to the xc/xc/ directory in the DRI cvs tree and run:
diff -urN /tmp/wiki.zQSGlf/wiki/text/LinusTorvalds /home/groups/d/dr/dri/wiki/text/LinusTorvalds
--- /tmp/wiki.zQSGlf/wiki/text/LinusTorvalds	1969-12-31 16:00:00.0 -0800
+++ /home/groups/d/dr/dri/wiki/text/LinusTorvalds	2004-02-26 09:04:14.0 -0800
@@ -0,0 +1,7 @@
+Linus Torvalds is great, but undoubtedly a proper nerd!
+
+Syrus is the win :D
+
+lor3 is teh lose!!!111
+
+BadGuy pwnz both tbh!
diff -urN /tmp/wiki.zQSGlf/wiki/text/Syrus /home/groups/d/dr/dri/wiki/text/Syrus
--- /tmp/wiki.zQSGlf/wiki/text/Syrus	1969-12-31 16:00:00.0 -0800
+++ /home/groups/d/dr/dri/wiki/text/Syrus	2004-02-26 09:13:06.0 -0800
@@ -0,0 +1,7 @@
+Best guy in the world.
+
+As far as gay ugly guys go that is
+
+hey at least I'm not you.
+
+You can't have everything you know?

---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&opÌk
--
___
Dri-patches mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-patchesforge.net
https://lists.sourceforge.net/lists/listinfo/dri-patches




---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Patch to cleanup DRM context handle on process exit

[Keith Whitwell]

Erdi Chen wrote:
This is a patch to call the context handles destructors and free the 
context bitmap entries when a process does not destroy its contexts 
before it exits. It saves context handles in a linked list in the 
drm_device struct.  I decided to use per device list instead of a per 
file descriptor list for simplicity because the number of contexts will 
usually be small.  A new semaphore, ctxlist_sem, is added to the 
drm_device struct because the patch will call functions that will down 
the struct_sem during list traversal.  The patch is generated against 
the DRI CVS tree that is updated at 02-19-2004.  It should also apply to 
the VIA branch with the exception that the line that calls sema_init 
would fail.
I've committed this, but I'm just about to leave on holidays.  If there are 
any problems hopefully Erdi will be able to submit fixup patches & have them 
committed while I'm away.

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Patch to cleanup DRM context handle on process exit

[Keith Whitwell]

Erdi Chen wrote:
This is a patch to call the context handles destructors and free the 
context bitmap entries when a process does not destroy its contexts 
before it exits. It saves context handles in a linked list in the 
drm_device struct.  I decided to use per device list instead of a per 
file descriptor list for simplicity because the number of contexts will 
usually be small.  A new semaphore, ctxlist_sem, is added to the 
drm_device struct because the patch will call functions that will down 
the struct_sem during list traversal.  The patch is generated against 
the DRI CVS tree that is updated at 02-19-2004.  It should also apply to 
the VIA branch with the exception that the line that calls sema_init 
would fail.

Thanks,
Erdi Chen
The patch looks ok to me, though I really don't know the code in this area 
particularly well.  Any comments from anyone before applying?

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRM leaking context handles?

[Keith Whitwell]

Alan Cox wrote:
On Iau, 2004-02-19 at 03:10, Erdi Chen wrote:

Is this a known problem? Has it been fixed? I have to add a linked list 
to VIA's DRM to keep track of context handles and perform clean up when 
release is called on the DRI file descriptor. I will gladly create a 
patch if this is a real problem.


I think that is probably the right approach. Userspace has no guaranteed
way of issuing a cleanup. Can you cc me a copy of the patch ?
Please send it to the list as well...

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] [r200] regression in "ipers" wireframe do not work with fog

[Keith Whitwell]

Dieter Nützel wrote:
Cheers,
Dieter
Probably worth posting this on Mesa lists as it is likely to pertain to the 
changes Brian's made recently to the fog code.

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] newdrm prelim. docs & no CVS write access (Was: mach64 and new tree)

[Keith Whitwell]

Daniel, Eric -- any ideas?

José Fonseca wrote:
I've put the Doxygen documentation of the DRM work I have done till now
at . The most
interesting tidbits are the new DMA buffer API described in
 and
.
BTW, I can't commit anything to CVS (or even make a diff) because
appearently I no longer belong to the "dri" group in dri.freedesktop.org
and can't create locks in /cvs/dri/... How can I remedy this?
José Fonseca


---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] blend color...

[Keith Whitwell]

Roland Scheidegger wrote:
Ok, I was wrong that the radeon driver also doesn't implement this 
correctly. It just always uses a fallback, it just doesn't support it in 
hardware. That said, I'm wondering what's the purpose of announcing 
ARB_imaging support, at least out of the three blend extensions this 
includes (EXT_blend_color, EXT_blend_minmax, EXT_blend_subtract) two 
aren't supported at all and the third (blend_subtract) only half. 
Rasterization fallbacks are evil...
I'm of the same opinion - I'd rather see the extensions accurately reflect 
what the card is capable of.

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] R100 tcl and ut2003_demo, (since "using MULT instead of PREMULT...")

[Keith Whitwell]

Michel DÃnzer wrote:
On Sat, 2004-02-14 at 00:11, Roland Scheidegger wrote:

Just the other day, I've noticed not even the good old tuxracer runs 
correct on the R100 on my 2nd PC - the ice areas flickered a lot, 


That's a long standing tuxracer bug, Z fighting between several passes.
I think there might be an r100 bug which contributes to the problem - 
specifically I'm not sure PolgonOffset is working correctly on the r100.

There is HW support for offset, but I'm not sure it works.

Anyway, I'm also pretty sure that polygon offset is broken in the SWTCL 
fallback modes of the r100 because of the support in that hardware of a 
viewport matrix.  The calculations to perform offset in software are based on 
vertices containing window coordinates, but because of the hardward viewport 
matrix, the r100 swtcl vertices only contain clipspace or NDC coordinates.

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] r200 / radeon blend trouble

[Keith Whitwell]

Roland Scheidegger wrote:
Keith Whitwell wrote:

ok, I'll try to implement it. This register is just before the
ABLENDCNTL and CBLENDCNTL, so that makes it easier to support these (for
the GL_EXT_blend_xx_separate extensions) at the same time. Unfortunately
requires a drm change, and unfortunately though I think it needs a new
state atom (since appending to the ctx atom won't work, as it wouldn't
be compatible at all to old drm modules). It's a pity that appending to
the ctx atom won't work, as this would have avoided some strange problem
(ABLENDCNTL and CBLENDCNTL are not sompletely separate registers from
BLENDCNTL, i.e. writing to BLENDCNTL will affect either ABLENDCNTL or
CBLENDCNTL or both, not sure yet since I still lack a test application.
That's a problem since the ctx atom gets emitted a lot, and thus the
previous updates to ABLENDCNTL and CBLENDCNTL in a different state atom
get always overwritten. Maybe I'll figure out how the registers
interact to avoid just always resubmitting ABLENDCNTL and 
CBLENDCNTL...).   For only the blend_color extension this isn't a 
problem though.


You could create two new state atoms and just leave the old ctx atom 
for legacy.
As far as I can see though this would get very ugly, with lots of "if 
drm_version" code. And it might not be necessary (for instance if the 
BLENDCNTL register just "mirrors" the CBLENDCNTL,  but leaves the values 
in ABLENDCNTL alone then it would be no problem at all). Maybe I'll try 
a bit harder to come up with a sample application for 
gl_ext_blend_func_separate next week, then it would be quite easy to 
figure out how the xBLENDCNTL registers interact.
I don't see why -- in userspace, just up the required drm minor number.  In 
kernel space just define two new atoms (which happen to overlap the old one). 
 What's the problem?

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] r200 / radeon blend trouble

[Keith Whitwell]

Roland Scheidegger wrote:
Keith Whitwell wrote:


Am I missing something -- isn't this setting the appropriate blend 
modes?  Is the constant color not getting updated correctly?


Yes, exactly, the constant color isn't updated at all (so the color
 is _really_ constant ;-)). Mesa would call ctx->Driver.BlendColor to 
inform the driver of the changed color, but neither R200 nor Radeon 
implement it.

Wow.

OK, the r200 register is RB3D_BLENDCOLOR: 0x3218, it holds an ARGB 
color.
ok, I'll try to implement it. This register is just before the
ABLENDCNTL and CBLENDCNTL, so that makes it easier to support these (for
the GL_EXT_blend_xx_separate extensions) at the same time. Unfortunately
requires a drm change, and unfortunately though I think it needs a new
state atom (since appending to the ctx atom won't work, as it wouldn't
be compatible at all to old drm modules). It's a pity that appending to
the ctx atom won't work, as this would have avoided some strange problem
(ABLENDCNTL and CBLENDCNTL are not sompletely separate registers from
BLENDCNTL, i.e. writing to BLENDCNTL will affect either ABLENDCNTL or
CBLENDCNTL or both, not sure yet since I still lack a test application.
That's a problem since the ctx atom gets emitted a lot, and thus the
previous updates to ABLENDCNTL and CBLENDCNTL in a different state atom
get always overwritten. Maybe I'll figure out how the registers
interact to avoid just always resubmitting ABLENDCNTL and 
CBLENDCNTL...).   For only the blend_color extension this isn't a 
problem though.
You could create two new state atoms and just leave the old ctx atom for legacy.

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] r200 / radeon blend trouble

[Keith Whitwell]

Am I missing something -- isn't this setting the appropriate blend 
modes?  Is the constant color not getting updated correctly?
Yes, exactly, the constant color isn't updated at all (so the color is 
_really_ constant ;-)). Mesa would call ctx->Driver.BlendColor to inform 
the driver of the changed color, but neither R200 nor Radeon implement it.

Wow.

OK, the r200 register is RB3D_BLENDCOLOR: 0x3218, it holds an ARGB color.

I can't find the r100 equivalent, but it'd be worth trying the same address. 
I'll let you know if I manage to dig it up.

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mach64 and new tree

[Keith Whitwell]

Dave Airlie wrote:

So should we just work on getting everything running on newtree then and not
worry about the security issues for now?


Sounds good to me, I'll look into disabling DMA by default, if we have the
option we are okay, my only issue is though should there be something in
the DRM that it affects? I can't see how XF86Config could make it safe, if
I have a DRM that allows it I can access it from userspace process without
DRI or XFree86...
XF86Config should only be modifiable by root, so if root decides to be 
insecure, that's root's business.

BTW, if you're working with vertices, you should definitely be using the new 
t_vertex.c code (see the i830 driver) if at all possible.  It can be extended 
to cover some more scenarios if necessary -- perhaps we need to allow driver 
extensions to that code.

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] r200 / radeon blend trouble

[Keith Whitwell]

Roland Scheidegger wrote:
When I was playing around with texenv (I'm trying to implement 
GL_EXT_blend_func_separate and GL_EXT_blend_equation_separate for the 
R200, though my attempts to modify texenv to make it a useful test for 
that were unsuccesful), I've noticed that the radeon and r200 driver 
announce GL_EXT_blend_color (because it's part of the imaging subset), 
but neither one implements it at all. Unsurprisingly, it doesn't work 
(seems to use some sort of a default color, though not the Open GL 
default color for this extension).
I've looked throgh the r200_reg.h and radeon_reg.h but couldn't find an 
obvious register to store the constant blend color. In fact, ATI says 
GL_EXT_blend_color isn't available on the R100, so maybe this needs a 
different approach. Any ideas?
Are you sure?  It looks like the code is all there in r200_state.c:

void r200BlendFuncSeparate( ... )
{
...
   case GL_CONSTANT_COLOR:
  b |= R200_SRC_BLEND_GL_CONST_COLOR;
  break;
   case GL_ONE_MINUS_CONSTANT_COLOR:
  b |= R200_SRC_BLEND_GL_ONE_MINUS_CONST_COLOR;
  break;
   case GL_CONSTANT_ALPHA:
  b |= R200_SRC_BLEND_GL_CONST_ALPHA;
  break;
   case GL_ONE_MINUS_CONSTANT_ALPHA:
  b |= R200_SRC_BLEND_GL_ONE_MINUS_CONST_ALPHA;
  break;
}
Am I missing something -- isn't this setting the appropriate blend modes?  Is 
the constant color not getting updated correctly?

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] copy and past and s/r200/radeon/.

[Keith Whitwell]

Mike Mestnik wrote:
--- Roland Scheidegger <[EMAIL PROTECTED]> wrote:

copy&paste job, I didn't touch anything in the code at all (except 
replacing "r200" with "radeon" a couple of times...). That said, I 


I'v heard this alot so I just thought I'd say even thought it's not my place.  Don't 
you think it
would be nicer to have a define like __RDRIVERNAME, then it would be just copy&past.  
Jusy my 2
cents.
There's a lot of shared code but as Roland has discovered, there are 
differences between the hardware which aren't being exploited -- the r200 is 
in a lot of cases being treated like an r100, but could in fact do a lot more.

A refactoring of the drivers could eliminate a lot of code, but it's important 
not to go too far.

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mach64 and new tree

[Keith Whitwell]

José Fonseca wrote:
If it's OK to sacrifice some speed in order to make the mach64 driver
secure and elegible to go the the trubk then there is quite a simple
solution: disable DMA by default (using the MMIO pseudo-DMA). Users still
have the option to force DMA in XF86Config if they so wish. 

I think this would make most people happy, as users no longer had to
download snapshots, and for the developers it would be easier too as no
further HEAD merges would be necessary.
This seems like a good way forward.

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] XFree86 local root exploit

[Keith Whitwell]

Roland Scheidegger wrote:
There's a buffer overflow in XFree86 allowing local attackers to gain 
root privileges. Here's the patch, 
ftp://ftp.xfree86.org/pub/XFree86/4.3.0/fixes/fontfile.diff the advisory
http://www.idefense.com/application/poi/display?id=72&type=vulnerabilities&flashstatus=false 
and a demo exploit also already has been published. I think it would be 
a good idea if someone could apply the patch to the dri cvs (applies 
with some fuzz and offset), if it is vulnerable.
I've committed the change.

Keith



---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa / DRI r200 crashes

[Keith Whitwell]

Roland Scheidegger wrote:
Brian Paul wrote:

Roland Scheidegger wrote:

Brian Paul wrote:

Keith Whitwell wrote:

Roland Scheidegger wrote:

I get a lot of dri crashes, were there some changes very recently 
in the tnl code? The crashes sometimes are predictable (for 
instance in the old ut it'll always crash in the intro when the 
announcer says "in twenty-two ninety-" segfault!)
gdb says this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4566)]
0x458bce72 in ?? ()
(gdb) bt
#0  0x458bce72 in ?? ()
#1  0x3cace852 in neutral_VertexAttrib2fvNV (index=9, v=0xa3812f4) 
at vtxfmt_tmp.h:384
#2  0x3ca40c41 in _ae_loopback_array_elt (elt=28) at 
api_arrayelt.c:828
#3  0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408, 
start=29, count=34) at t_array_api.c:57
#4  0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, 
count=171564768) at t_array_api.c:153






This looks like something which Brian has been working on recently.




Roland, can you back up to _ae_loopback_array_elt() and 'print 
*at->array'?


Certainly.
#2  0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828   at->func( at->index, src );
(gdb) print *at->array
$1 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr = 
0xa38104c "ø\005\202?ø\005\202?", Enabled = 1,
  Normalized = 0 '\0', BufferObj = 0xa39aae0, _MaxElement = 
20, Flags = 1}

My guess is that the src pointer is invalid for some reason.  The 
pointer arithmetic looks OK though.

Basically, the glArrayElement() fallback code wasn't handling 
glVertexAttrib arrays.  I added that and expressed the 
multi-texcoord arrays in terms of vertex attribs.  Vertex attribute 
9 corresponds to texcoord array 1.

In gdb, also check if at->array == ctx->Array.TexCoord[1].


#2  0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828   at->func( at->index, src );
(gdb) print at->array
$4 = (const struct gl_client_array *) 0xa3b2c38
(gdb) print ctx->Array.TexCoord[1]
Cannot access memory at address 0x14d89
(2 levels up)
#4  0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768) 
at t_array_api.c:153
153   fallback_drawarrays( ctx, mode, start, start + count );
(gdb) print ctx->Array.TexCoord[1]
$5 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr = 
0xa381054 "", Enabled = 1, Normalized = 0 '\0',
  BufferObj = 0xa39aae0, _MaxElement = 20, Flags = 1}


Two things:

1. It's strange that ctx->Array.TexCoord[1] is an invalid address in 
_ae_loopback_array_elt() but valid in _tnl_DrawArrays().

2. The count parameter to _tnl_DrawArrays() is _really_ large.  What's 
up with that?


I believe both problems are just debugger problems. I know I've seen the 
second problem quite a few times (the debugger just seems to fail to 
grab the right value for parameters in the function parameter list, 
possibly due to optimizations?). And I believe the first problem can 
also happen just because of the debugger (btw it's gdb 5.2.1 and gcc 
3.2, it might be better nowadays).
If you compile without -O2 (edit host.def), these problems should go away.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Mesa / DRI r200 crashes

[Keith Whitwell]

Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently in the 
tnl code? The crashes sometimes are predictable (for instance in the old 
ut it'll always crash in the intro when the announcer says "in 
twenty-two ninety-" segfault!)
gdb says this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4566)]
0x458bce72 in ?? ()
(gdb) bt
#0  0x458bce72 in ?? ()
#1  0x3cace852 in neutral_VertexAttrib2fvNV (index=9, v=0xa3812f4) at 
vtxfmt_tmp.h:384
#2  0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
#3  0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408, 
start=29, count=34) at t_array_api.c:57
#4  0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768) at 
t_array_api.c:153
This looks like something which Brian has been working on recently.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon_lighting.c needed?

[Keith Whitwell]

Roland Scheidegger wrote:
Now that I've commited the lighting changes for r200 (still has the 
material fallback though), I've wanted to commit the same changes (well 
not exactly the same of course ;-)) to the radeon driver too (some brief 
testing showed it worked just fine). But I'm a bit confused, the code 
I'll need to touch is both in radeon_state.c as well as 
radeon_lighting.c. As far as I can see, radeon_lighting.c is an attempt 
to separate some code out of the radeon_state.c but the file is not used 
anywhere. So, should I still update this file too? I think it's a bit 
ugly to have duplicated code...

I think it can be left alone at this point.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa / radeon / r200 texrect fixes

[Keith Whitwell]

Roland Scheidegger wrote:
Here are the cleaned-up texrect fixes - last time there was still some
disagreement about how some things should be fixed.
If there are no objections I'm just going to try out my newly aquired
super-powers and commit it ;-).


Roland

(btw sorry if this appears twice on the list. The mail list server seems 
to have silently dropped it the first time.)

Looks OK to me.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mach64 and new tree

[Keith Whitwell]

Dave Airlie wrote:
track him down at some point, but for now I'd like to bring the current
branch up to the top of tree at least,
So should I use the mesa tip and start a new mach64 branch on the DRI tree
or should I make a branch on both trees?
oh yeah I'm unsure who brought it up on IRC so if you are on the list
speak up :-)


I've just brought the mesa driver from mach64-0-0-6 so it compiles in the
top of the Mesa tree (I doubt it works, but building is a good start)
so if someone tells me where to put it I'll commit it for a start point
tomorrow (I'm GMT+10, should probably use .au a/c :-)
I'll work on the XFree bits and the DRM should be similiar enough soon..
I think it should be fine to go in at Mesa head.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] fix for i810 issues of late..

[Keith Whitwell]

Keith Whitwell wrote:
Dave Airlie wrote:

I think I'll give up for today and go at it again later, perhaps the 
i810
just can't do this in hardware and I need to fallback or perhaps the
number of vertices being output is out by one .. who knows :-)


Okay I found it and checked in the fixes for it, the macro expansion was
catching the code on ALLOC_VERTS(nr+1) for i810,i830 and mga, these all
did nr * x type things, instead of (nr) * x in their ALLOC_VERTS macro
expansions..
Funny enough I now know how the mesa vertex code works very well!!!

I'll be hiding for a while I think.. my brain is fried...


Nice one Dave.  It's worth checking the rest of the drivers for this as 
well.
Ah, OK, I see you already have...

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] fix for i810 issues of late..

[Keith Whitwell]

Dave Airlie wrote:
I think I'll give up for today and go at it again later, perhaps the i810
just can't do this in hardware and I need to fallback or perhaps the
number of vertices being output is out by one .. who knows :-)


Okay I found it and checked in the fixes for it, the macro expansion was
catching the code on ALLOC_VERTS(nr+1) for i810,i830 and mga, these all
did nr * x type things, instead of (nr) * x in their ALLOC_VERTS macro
expansions..
Funny enough I now know how the mesa vertex code works very well!!!

I'll be hiding for a while I think.. my brain is fried...
Nice one Dave.  It's worth checking the rest of the drivers for this as well.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] r200 new "revolutionary" lighting

[Keith Whitwell]

Roland Scheidegger wrote:
Keith Whitwell wrote:

Roland Scheidegger wrote:

Ronny V. Vindenes wrote:

OK, I've spent a few hours playing with the updated patch today, and
all I can say is: Good work! It fixes lighting and fog issues in many
cases (including one program that segfaults without it). Also, in
most the programs I've tested there are small performance
improvements* (~5 fps), but the most noticable improvement (other
than visual issues) is that cpu load is much lower now, especially in
combination with wine.


good to know. Those things I tested didn't really get much of a 
performance improvement, except some of the specviewperf benchmarks 
(probably those which used two-sided lighting).

I haven't found any regressions, and unless someone finds some big 
error, I think this should be merged asap.


Not so fast, I did find some errors, though they are strange. Both 
can easily be seen with specviewperf 7.1 proe-02. First, the 
elimination of the tcl fallback if materials between begin/end were 
discovered introduced some severe rendering errors (looks like the 
wrong materials are used in some parts of the car).
Second, and I have absolutely no idea what the heck caused this, 
running the same proe-02 test with tcl_mode=0 now causes a segfault. 
The patch doesn't seem to touch anything which could be related to 
that (and the reintroduction of the material between begin/end 
fallback didn't help here neither), any ideas?
gdb shows this:
Program received signal SIGSEGV, Segmentation fault.
triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at 
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179
179   GLfloat (*vbcolor)[4] = VB->ColorPtr[1]->data;
(gdb) bt
#0  triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at 
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179


Looks like the triangle function chosen by the driver is out of step 
with the actual state.  IE, the trifunc is set for two-sided lighting, 
but it hasn't actually been performed, because it's not enabled.

This is occuring in a swtcl fallback, so the code to look at is 
probably called r200ChooseRenderFunc() or similar in r200_swtcl.c.

It could also be the opposite, that 2-sided lighting hasn't been 
performed when it should have been, but I think this less likely.

Keith


Oops! You're right on track, I've removed the call to 
r200ChooseRenderstate when the lighting model changed to two-side 
together with the twoside fallback check. Really bad idea, works now again.

The rendering errors are a harder problem though, I can see now why the 
material between begin/end fallback was needed in the first place. There 
doesn't seem to be an easy way currently to submit material changes 
between vertices, so it looks like the fallback needs to stay (even 
though it doesn't really seem to work correctly neither for some reason).
Certainly the bug with the current code should be resolved - I can't think 
it's too difficult - as the r100 will need it.

The r200 *can* do material changes inside begin/end - basically by using the 
R200_LM1_SOURCE_VERTEX_COLOR_0..7 arrays to track the material attributes and 
then wiring each of these up just like in the glColorMaterial case.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] fix for i810 issues of late..

[Keith Whitwell]

Dave Airlie wrote:
Since Keith's tnl_dd_dmatmp.h patches on the 11 Dec last year, the
poor i810 has been seriously fubar, I've just gotten time to look at it
now (well I've been staring at it on and off for weeks with a blank)
The fix is up at
http://freedesktop.org/~airlied/i810_render_fix.diff
I've taken it from the i830 code, and I've modified scale_prim so that the
3rd element is also a fallback case,
This is GL_LINE_LOOP?  That makes sense.

Keith can you tell me if my numbers are correct for the i810? or at least
where you got the numbers for the i830...
The number is the number of HW vertices emitted per incoming vertex in the 
fallback path.  So for things like

GL_POINTS --> 1 if rendering with a HW point prim
  --> 4 if rendering with a HW quad or trifan prim (unlikely)
  --> 6 if rendering with 2 triangles
GL_LINES --> 1 if rendered with a HW line prim
 --> 3 if rendered with 2 tris/line
GL_LINE_LOOP
GL_LINE_STRIP --> 2 if rendering with HW line prim
  6 if rendered with 2 tris/line
and so on...

if no major objections I'll apply it soon, I'd like to just figure out the
values for scale_prim are correct...
fixes, blender and tri sample program among others...
Interesting - this should only be a heuristic to choose the fastest path, not 
have any correctness value.  Correctness should be ensured by 
i810_validate_render, from t_dd_dmatmp.h.  Can you try & find out what's going 
wrong with that?

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] r200 new "revolutionary" lighting

[Keith Whitwell]

Michel DÃnzer wrote:
On Mon, 2004-02-02 at 23:11, Alan Hourihane wrote:

On Mon, Feb 02, 2004 at 11:09:57PM +0100, Michel DÃnzer wrote:

On Mon, 2004-02-02 at 23:08, Alan Hourihane wrote:

On Mon, Feb 02, 2004 at 10:48:15PM +0100, Michel DÃnzer wrote:

About keeping track of your patches: I wonder what others think about
giving you [Roland Scheidegger] write access?
Go for it.
I would, but I can't.
Maybe Eric can do it, but I think there should be others with Eric's
access ability so these others can do it too.


At any rate, we should probably wait for Keith's opinion.
Yep, all for it, in fact I finally woke up to just how much work Roland has 
been doing a couple of days ago and "popped the question" in another email... 
 If he doesn't have it already, it's down to the fd.o guys to sort it out.  I 
think Eric's on holiday.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] r200 new "revolutionary" lighting

[Keith Whitwell]

Roland Scheidegger wrote:
Ronny V. Vindenes wrote:

OK, I've spent a few hours playing with the updated patch today, and
all I can say is: Good work! It fixes lighting and fog issues in many
cases (including one program that segfaults without it). Also, in
most the programs I've tested there are small performance
improvements* (~5 fps), but the most noticable improvement (other
than visual issues) is that cpu load is much lower now, especially in
combination with wine.
good to know. Those things I tested didn't really get much of a 
performance improvement, except some of the specviewperf benchmarks 
(probably those which used two-sided lighting).

I haven't found any regressions, and unless someone finds some big 
error, I think this should be merged asap.
Not so fast, I did find some errors, though they are strange. Both can 
easily be seen with specviewperf 7.1 proe-02. First, the elimination of 
the tcl fallback if materials between begin/end were discovered 
introduced some severe rendering errors (looks like the wrong materials 
are used in some parts of the car).
Second, and I have absolutely no idea what the heck caused this, running 
the same proe-02 test with tcl_mode=0 now causes a segfault. The patch 
doesn't seem to touch anything which could be related to that (and the 
reintroduction of the material between begin/end fallback didn't help 
here neither), any ideas?
gdb shows this:
Program received signal SIGSEGV, Segmentation fault.
triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at 
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179
179   GLfloat (*vbcolor)[4] = VB->ColorPtr[1]->data;
(gdb) bt
#0  triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at 
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179
Looks like the triangle function chosen by the driver is out of step with the 
actual state.  IE, the trifunc is set for two-sided lighting, but it hasn't 
actually been performed, because it's not enabled.

This is occuring in a swtcl fallback, so the code to look at is probably 
called r200ChooseRenderFunc() or similar in r200_swtcl.c.

It could also be the opposite, that 2-sided lighting hasn't been performed 
when it should have been, but I think this less likely.

Keith





---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] r200 new "revolutionary" lighting

[Keith Whitwell]

Roland Scheidegger wrote:
Hello again

now that the lighting bugs are finally mostly gone, I've just gone ahead 
and changed the lighting code a bit more... (patch against cvs, without 
the earlier colormat fix).
This patch causes the driver to no longer use the PREMULT lighting, 
instead it will use the SOURCE_MATERIAL stuff. Looking at r200_reg.h it 
looked to me like the chip can handle a lot what is currently done in 
software. So I changed that ;-)
Most of the restrictions in the r200 code are caused by the driver being 
forked off the original radeon - the restrictions relate to that chip, not the 
r200.  Lifting them has been a long-time todo item.  The new tnl code which 
treats materials in much the same way as other vertex attributes was a step in 
this direction.

What's new:
- no more bazillion calls of update_light_colors with lots of color 
multiplications, since the chip handles that now itself.
- two-side-lighting with different materials no longer causes a tcl 
fallback (so samples/fog now runs correctly, of course if you use 
tcl_mode=0 it is still hosed - it looks like the tcl fallback if both 
fog and two-side lighting are enabled is broken on both radeon and r200, 
but that's another topic. It was the starting point for this patch 
however, but I was unable to figure out what's wrong with the fallback. 
The tnl stuff is scary :-().

- removed the strange fallback if materials between begin / end were 
discovered. Couldn't figure out why it was there (the comment said the 
chip handles it just fine?), I thought maybe because material changes 
caused for instance lighting updates, which now no longer happens. Well 
so far it didn't lock up...
Another hangover from the r100, which can't handle this at all.  The r200 
should do just fine.

There are some things I'm unsure about. For one, the 
update_global_ambient now has an impossible if condition, but I have no 
idea if the function works correctly now or not - it could also work 
better than before, who knows ;-). There's also a lot of guesswork 
involved, but at first glance things seemed to look quite good - the 
patch passes the nwn and glxgears test ;-) (and some others too, but 
didn't test extensively yet).



Maybe I missed something important and this lighting code fails in some 
cases horribly, but if not I think this lighting code would be much 
nicer (it should likely also help TNL performance quite a bit, unless 
you run on a P5 10Ghz). The code is also quite a bit simpler than before 
IMHO, most of the code is just two large copy/paste if statements.
No, just clearing out the cobwebs.  Good work.  I'll try and have a closer 
look at the patch.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: Question about texmem.c

[Keith Whitwell]

Ian Romanick wrote:
Keith Whitwell wrote:


I'm wondering if this has been thought through.  For the test to work, 
this code fragement will have to be re-evaluated whenever 
tObj->MinFilter changes, or at least whenever it changes to/from 
NEAREST or LINEAR.

I don't think the drivers do this at the moment.  Correct?


This function was the result of a code refactor.  All of the drivers had 
a bit of code like this in their SetTexImages function.  I just pulled 
the code out of those individual functions are replaced it with a call 
to driCalculateTextureFirstLastLevel.  So, the values of firstLevel and 
lastLevel may get out-of-date, but they are re-evaluated when they are 
actually needed.  To keep them completely upto date (which I don't think 
is necessary, we'd have to call driCalculateTextureFirstLastLevel whenever:

1. The texture size changed.
2. MinLod or MaxLod changed.
3. The texture filter changed.
Indeed - my point being that I don't think we do call it under (all of) those 
circumstances.

The importance of firstLevel/lastLevel is that they specify which mipmaps to 
upload, if they aren't correct, how can we have confidence that the right set 
of mipmaps are on the card?

At the moment, in most drivers, this function doesn't get called unless at 
least one texture level (t->base.dirty_images[0] != 0) is going to be uploaded 
- which isn't really what you want to happen every time you change some of 
that state.

I'm pretty sure that the i830 driver didn't have the test on tObj->MinFilter, 
fwiw, possibly due to conform or glean testing done near the end of its 
development.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Question about texmem.c

[Keith Whitwell]

In driCalculateTextureFirstLastLevel, there's this bit of code:

 if (tObj->MinFilter == GL_NEAREST || tObj->MinFilter == GL_LINEAR) {
 /* GL_NEAREST and GL_LINEAR only care about GL_TEXTURE_BASE_LEVEL.
  */
 firstLevel = lastLevel = tObj->BaseLevel;
  }
  else {
 firstLevel = tObj->BaseLevel + (GLint)(tObj->MinLod + 0.5);
 firstLevel = MAX2(firstLevel, tObj->BaseLevel);
 lastLevel = tObj->BaseLevel + (GLint)(tObj->MaxLod + 0.5);
 lastLevel = MAX2(lastLevel, t->tObj->BaseLevel);
 lastLevel = MIN2(lastLevel, t->tObj->BaseLevel + baseImage->MaxLog2);
 lastLevel = MIN2(lastLevel, t->tObj->MaxLevel);
 lastLevel = MAX2(firstLevel, lastLevel);
  }
I'm wondering if this has been thought through.  For the test to work, this 
code fragement will have to be re-evaluated whenever tObj->MinFilter changes, 
or at least whenever it changes to/from NEAREST or LINEAR.

I don't think the drivers do this at the moment.  Correct?

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Bogus(?) assertions in radeon driver

[Keith Whitwell]

Felix Kühling wrote:

I was wrestling with the Mesa build process for a while. Maybe I should
have RTFM. ;-) Anyway, I do get the same error with seccolor.
OK, I"ve committed something which should help...

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] r200 texrect (current mesa/dri cvs) trouble

[Keith Whitwell]

Ian Romanick wrote:
Keith Whitwell wrote:

Roland Scheidegger wrote:

@@ -888,9 +1070,9 @@
_mesa_lookup_enum_by_nr( pname ) );
}
-   if ( ( target != GL_TEXTURE_2D ) &&
+/*   if ( ( target != GL_TEXTURE_2D ) &&
 ( target != GL_TEXTURE_1D ) )
-  return;
+  return;*/


Wouldn't this change be enough on its own?  This test is broken & has 
probably been causing subtle problems for ages.


Wow.  That *is* broken.  The R100 driver has a similar problem.  Instead 
of removing it, shouldn't the test be updated?  Perhaps a change similar 
to the one I made in r200BindTexture would be in line? 
I don't see any reason not to keep all texture objects uptodate.  It's not 
going to alter performance in the case where the app is doing lots of work on 
non-supported texture dimensions, as there'll be fallbacks all over the place 
anyway.  Why not just go for the obviously-correct solution & ditch the test?

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon bugs

[Keith Whitwell]

Otto Solares wrote:
On Tue, Jan 27, 2004 at 08:41:45PM +, Keith Whitwell wrote:

What I'd really like to be able to do now is build the dri drivers directly 
out of the Mesa tree.


Does this means that finally we will see XFree and linux-solo build
it's drivers from Mesa-newtree/src/drivers/dri or this is not the
case yet?
I can't say what XFree will do, but I doubt they'd suddenly stop using Imake 
and jump on whatever we provide.

Rather, it'll mean that you can build the drivers either directly from a Mesa 
tree, or using the current method via an XFree86 or DRI cvs tree pointed at or 
containing a Mesa tree.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] r200 texrect (current mesa/dri cvs) trouble

[Keith Whitwell]

Roland Scheidegger wrote:
(since the original email never made it to the list, a new one - it's 
not a resend though)

texrect is broken here (and I've no idea why it works for other people 
;-)).
There are 2 problems in the driver which cause this:
First, if glGenTextures is called, there is no texture target yet. This 
will cause the r200 driver (in r200AllocTexObj) to initialize the 
texture min filter to GL_NEAREST_MIPMAP_LINEAR. The problem is when the 
texture object is now bound to a RECTANGLE_NV target, the min filter 
will not change, causing havoc (the also illegal clamp mode doesn't seem 
to hurt much).
Second problem is the r200TexParameter, it will only do anything for 1D 
and 2D targets - thus, even if an application explicitly sets a 
different texture filter, the hardware will still try to use mipmapping 
for rectangle targets. Removing the target condition will fix this (why 
is it there? Mesa already should have checked illegal combinations, or 
are there some OGL compliant target/param combinations which are not 
supported in hardware?)
Both problems are also present in the radeon driver, but texrect seems 
to work there nonetheless...

attached a quick patch (only for r200, and I doubt it will attach 
cleanly, but I guess it's too ugly anyway).




@@ -888,9 +1070,9 @@
   _mesa_lookup_enum_by_nr( pname ) );
}
-   if ( ( target != GL_TEXTURE_2D ) &&
+/*   if ( ( target != GL_TEXTURE_2D ) &&
( target != GL_TEXTURE_1D ) )
-  return;
+  return;*/
Wouldn't this change be enough on its own?  This test is broken & has probably 
been causing subtle problems for ages.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Bogus(?) assertions in radeon driver

[Keith Whitwell]

Roland Scheidegger wrote:
Felix Kühling wrote:

Again, commenting out the assertion helps. I'm not sure if the assertion
is bogus or if there is a real problem behind this that has to be
solved.
You get that also with the mesa test tests/seccolor (my email on that 
topic is still missing in action, crappy sf mail server...). IMHO the 
assertion is bogus, as the mesa derived state ctx->_TriangleCaps is only 
calculated later. Or maybe mesa needs to make sure that the derived 
state is current.
Ah, OK - the way Mesa calculates this changed in the last few days.  Probably 
the best thing to do is stop relying on that bit and use the macro 
NEED_SECONDARY_COLOR() instead.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon bugs

[Keith Whitwell]

Alan Hourihane wrote:


What I'd really like to be able to do now is build the dri drivers directly 
out of the Mesa tree.


Definately. Slate that up for 6.1, I'll certainly work on that issue.
It's not too hard - I had it working on the embedded branch a while ago.

In general, the Mesa make system could use a little modernization and spring 
cleaning.  It'd be nice to see what improvements could be made with minimal or 
no additional toolchain requirements.

Again - the embedded branch has/had a nice build system, although one that 
relied (very minimally) on GNU make.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon bugs

[Keith Whitwell]

Alan Hourihane wrote:
On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:

This is a good time to remind people/establish the principle that driver 
bug fixes should be propogated to the mesa-6_0_branch of the Mesa 
repository. Brian's always done a good job of making sure core mesa fixes 
get copied over, but it shouldn't come down to him alone.

In particular, the recent TCL lighting fixes for the radeon & r200 drivers 
should get pushed down into Mesa 6.0.


Do we want to bring Mesa 6.0's branch into the DRI repository now or
stick with the way we have it currently ?
I guess if we stick with the way it is now, then most developers will
track Mesa's trunk and we may start to lag stable releases.
I like the way we have it now, to be truthful.  If we develop on a branch or 
branches, we get little or no testing, and we really want testing.

If someone wants a stable branch, they will be able to get one.  It doesn't 
take too much effort to ensure bugfixes make their way onto the stable branch 
also.  If someone has a bug with the stable branch, the information that it is 
fixed on the trunk will help track it down.

What I'd really like to be able to do now is build the dri drivers directly 
out of the Mesa tree.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon bugs

[Keith Whitwell]

David Dawes wrote:
On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:

On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:

There are quite a few Radeon-related bugs still outstanding in
bugs.xfree86.org, including several related to DRI lockups.
Has anyone followed them up?
David,

I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4,
and the DRI developers aren't tracking Mesa 4.0.x anymore.


We are at Mesa 5.0.2.  Doesn't the DRI project maintain a Mesa
5.0.x-based stable branch of some sort?
David,

The hardware drivers are now being maintained in the Mesa tree.  Mesa does 
have a set of stable branches but the only one containing the DRI drivers is 
too recent for your purposes - Mesa 6.0.

This is a good time to remind people/establish the principle that driver bug 
fixes should be propogated to the mesa-6_0_branch of the Mesa repository. 
Brian's always done a good job of making sure core mesa fixes get copied over, 
but it shouldn't come down to him alone.

In particular, the recent TCL lighting fixes for the radeon & r200 drivers 
should get pushed down into Mesa 6.0.

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] (no subject)

[Keith Whitwell]

Dave Airlie wrote:
Well I've traced this a bit, an operation appears to be hanging the
chipset,
Keith, maybe you can tell me, in i830_span.c you no longer have a HW_LOCK
or HW_UNLOCK defined for the i830 has something happened elsewhere that
makes these unnecessary,
There are the i830SpanRenderStart() and i830SpanRenderFinish() callbacks from 
swrast which do the locking now.

what blender seems to be doing is loading up a string of glBitmaps to
create its frontend, and after a bunch of these a HW_LOCK call
from i810WriteRGBAPixels_565 calls DMAFinish which doesn't seem to have
finished for some reason from the previous one, any ideas why this might
happen?
If dma hasn't finished, the worst that will happen is some of the uploaded 
bitmap on the screen will be corrupted.

Maybe the vast number of HW_LOCK calls is an issue?

Keith



---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel