Re: [Dri-devel] UT2k3 playability status?
I totally agree with Phi here. As the author of three ATM drivers (which lie on the relatively nasty side of networking interfaces) and one accelerated 3D graphics driver (Permedia 2), I will attest to the fact that the accumulated pain of bringing all three ATM drivers to a level of reliability suitable for use in "production" environments was far less than than the pain of bringing the Permedia 2 driver to a level of "will work for some cool demos but is clearly not ready for prime time" Mike Philip Brown wrote: On Sun, Mar 30, 2003 at 02:27:46PM +0100, Ian Molton wrote: Theres *TONS* of other hardware [than video cards] that has open source drivers that *totally* rock. and the other hardware is a lot simpler to interface to. Kinda like the difference between writing a image display program, and writing a word processor, you might say. --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Databook and goal of Silicon Motion, Inc Lynx3DM (SM720) DRI driver
Rick Jones wrote: I have acquired a Silicon Motion, Inc. Lynx3DM (SM720) chip databook. I have a board with shared video memory and 4MB on the chip. You don't describe the circumstances under which you acquired the databook, but you should be -real sure- that the company won't take offense before you make any releated code available. My plans are.. 1. Making a minor patch to the XFree driver for this chip (to do a Left/Right mirror image). -- I hope to get my feet wet so to say with communicating with this chip with this. Some would say there is no such thing as a minor patch to XFree...especially the first patch, but that is a sensible approach. 2. Making a DRI driver for this chip. Considering this is a completely NEW driver for this project, is it better to make a preliminary driver first before getting cvs access to commit? YES!! You should be able to build it and test it in every torturous way you can think of before even thinking of committing it. Rick __ Post your free ad now! http://personals.yahoo.ca --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NURBs + Autonormal peculiarity
I have just rerun the nurb program on another machine which is running the distribution version of XFree86 4.2.0 which I downloaded as source and built on May 20, 2002. Accelerated rendering is on and working through an r128. This version appears to build libGLU 1.3 along with Mesa 3.4.2. The problem also persists there. So I think that the libGLU version is not the key -- but that probably Mesa 4.x may well contain the solution. Thanks for the help, Mike === Application Info == projects/glut-1.0 == ldd ./nurb4 | head -10 libGL.so.1 = /usr/lib/libGL.so.1 (0x40029000) libGLU.so.1 = /usr/X11R6/lib/libGLU.so.1 (0x401fd000) libglut.so.3 = /usr/lib/libglut.so.3 (0x4027) libm.so.6 = /lib/i686/libm.so.6 (0x402a2000) libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x402c5000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x402da000) libpthread.so.0 = /lib/i686/libpthread.so.0 (0x40392000) libc.so.6 = /lib/i686/libc.so.6 (0x403a7000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x404e2000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x404eb000) projects/glut-1.0 == ls -l /usr/X11R6/lib/libGLU* lrwxrwxrwx1 root root 13 May 20 18:06 /usr/X11R6/lib/libGLU.so - libGLU.so.1.3 lrwxrwxrwx1 root root 13 May 20 18:06 /usr/X11R6/lib/libGLU.so.1 - libGLU.so.1.3 -rwxr-xr-x1 root root 565207 May 20 18:06 /usr/X11R6/lib/libGLU.so.1.3 = XFree86 Info /local/share/westall/projects/glut == xdpyinfo | more name of display::0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:4020 XFree86 version: 4.2.0 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 == GLX Info /local/share/westall/projects/glut == glxinfo | more name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Rage128 20010405 Pro AGP 1x x86/MMX/SSE OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
[Dri-devel] NURBs + Autonormal peculiarity
The attached program illustrates a shading anomaly
we have encountered while attempting to use autonormal
in conjunction with nurbs.
The shading of the sphere is seriously screwed up
while running with indirect rendering on the standard
X server packaged with RH 7.3. It can be fixed by
uncommenting the /* #define CORRECT 1 */ on line 8.
The correction just sets normals manually.
The program runs fine on both native SGI systems and
with the accelerated NV driver + XFree86 + Linux.
Oddly enough the EXACT problem that occurs with unaccelerated
rendering on XFree86 also occurs with the OpenGL version
that comes with recent Sun Solaris boxes. Thus we
may well have a bug that is simply latent on SGI | NV.
If anyone sees it we would be interested in knowing
what it is.
Thanks,
Mike
James M. Westall
Professor of Computer Science
Clemson University
Clemson SC 29634
/*
* a sphere the hard way ...
* 2d nurb surface as profile_curve x swing_curve ...
* glEnable(GL_AUTO_NORMAL) doesn't seem to work on Linux systems;
* uncomment the #define CORRECT below to see correct display
*/
/* #define CORRECT 1 */
#include X11/Xlib.h
#include X11/Xutil.h
#include X11/Xos.h
#include X11/Xatom.h
#include stdio.h
#include math.h
#include GL/gl.h
#include GL/glx.h
#include GL/glu.h
int vattrib[] = {
GLX_RGBA,
GLX_DOUBLEBUFFER,
GLX_RED_SIZE,8,
GLX_GREEN_SIZE,8,
GLX_BLUE_SIZE,8,
GLX_DEPTH_SIZE,1, /* at least 1 means get largest */
None};
void do_display();
void nurbcity();
void do_material();
void do_lights();
main(argc,argv)
int argc;
char **argv;
{
Display *display;
Window rootw, win;
XSizeHints whisper;
XEvent report;
unsigned long eventmask;
int screen, width, height, bsz;
XVisualInfo *pgob;
XSetWindowAttributes attrib;
GLXContext ctx;
XColor white, black;
if((display=XOpenDisplay(NULL))==NULL){
fprintf(stderr,can't open\n);
exit(1);
}
screen = DefaultScreen(display);
width = 900;
height = 900;
rootw = RootWindow(display,screen);
pgob = glXChooseVisual(display,screen,vattrib);
attrib.colormap = XCreateColormap(display,rootw,pgob-visual,AllocNone);
white.red = 0x;
white.green = 0x;
white.blue = 0x;
black.red = 0;
black.green = 0;
black.blue = 0;
XAllocColor(display,attrib.colormap,white);
XAllocColor(display,attrib.colormap,black);
attrib.background_pixel = white.pixel;
attrib.border_pixel = black.pixel;
bsz=0;
win =
XCreateWindow(display,rootw,0,0,width,height,bsz,pgob-depth,InputOutput,pgob-visual,CWBorderPixel|CWColormap|CWBackPixel,attrib);
ctx = glXCreateContext(display,pgob,NULL,True);
glXMakeCurrent(display,win,ctx);
/* whisper some hints to strange Tom */
whisper.flags = PSize;
whisper.width=width;
whisper.height=height;
XSetWMNormalHints(display,win,whisper);
eventmask=ExposureMask|KeyPressMask;
XSelectInput(display,win,eventmask);
XMapWindow(display,win);
/* wait on expose */
XNextEvent(display,report);
while(report.type!=Expose) {
printf(do wah\n);
XNextEvent(display,report);
}
while(1){
switch(report.type){
case Expose:
do_display();
glXSwapBuffers(display,win);
break;
case KeyPress:
glXDestroyContext(display,ctx);
XCloseDisplay(display);
exit(0);
default:
sleep(1);
}
XNextEvent(display,report);
}
}
struct point {
float x;
float y;
float z;
};
void do_display()
{
struct point eyept, viewpt, up;
eyept.x = 0.0; eyept.y = 0.0; eyept.z = 5.0;
viewpt.x = 0.0; viewpt.y = 0.0; viewpt.z = 0.0;
up.x = 0.0; up.y = 1.0; up.z = 0.0;
glEnable(GL_DEPTH_TEST);
glShadeModel(GL_SMOOTH);
glClearColor(0.3,0.0,0.3,0.0);
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
/* carve out gob */
gluPerspective(45.0,1.0,0.1,20.0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
gluLookAt(eyept.x,eyept.y,eyept.z,viewpt.x,viewpt.y,viewpt.z,up.x,up.y,up.z);
#ifndef CORRECT
glEnable(GL_AUTO_NORMAL);
#endif
glEnable(GL_NORMALIZE);
do_material();
do_lights();
nurbcity();
}
/* control points and degree in each direction */
/* swing curve ... u */
#define N 9
#define K 2
/* profile curve ... v */
#define M 5
#define L 2
/* swing in x-z plane */
struct point swing_crtl_pts[N] = {
{1.0,0.0,0.0},
{1.0,0.0,1.0}, {0.0,0.0,1.0}, {-1.0,0.0,1.0},
{-1.0,0.0,0.0},
{-1.0,0.0,-1.0}, {0.0,0.0,-1.0}, {1.0,0.0,-1.0},
{1.0,0.0,0.0}
};
/* profile in x-y plane */
struct point profile_crtl_pts[M] = {
{0.0,1.0,0.0},
{1.0,1.0,0.0},
{1.0,0.0,0.0},
{1.0,-1.0,0.0},
{0.0,-1.0,0.0}
};
float swing_weights[N] = {
1.0,M_SQRT1_2,
1.0,M_SQRT1_2,
1.0,M_SQRT1_2,
1.0,M_SQRT1_2,
1.0};
float profile_weights[M] = {
1.0,M_SQRT1_2,
1.0,M_SQRT1_2,
1.0};
float uknots[N+K+1] = {
0.0,0.0,
[Dri-devel] Fast Draw Pixels for MGA
We are working on a fairly large scale distributed rendering project at Clemson in which the actual display is done via glDrawPixels using a Matrox G450. We would like to make this as fast as possible and my grad assistant found a dri web page saying that there is a description of the GL state that produces very very fast draw/read pixels, and can be found in /lib/GL/mesa/src/drv/mga/DOCS. Unfortunately this directory seems to have disappeared from the CVS and the XFree source trees. We would be most grateful if someone could point us to the current location of this document (or just tell us what the magic state is). Thank you, Mike James M. Westall Professor and Director of Graduate Affairs Department of Computer Science Clemson University Clemson SC 29634 USA ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3dlabs Oxygen VX1 32MB AGP
There is no hope of that working. The only 3DLabs chip set ever supported by DRI was the Glint MX with Gamma front end. Your board is not based on that. Oddly, from your log it would appear that the 2-D accelerator is treating this board as a Permedia-3 even though 3-DLabs no longer uses that term in any of their literature and instead refers to it as the Glint R3. Mike ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Restoring DRM Library Device Independence
To be a bit more specific the 2.4.x sound system now loads something like (on my system) soundcore.o ~ drm_core.o cs46xx.o ~ drm_radeon.o (plus codec modules) Mike Michael wrote: On Thu, Mar 28, 2002 at 10:13:04AM +, Keith Whitwell wrote: Linus is pretty clear that he'd only accept a single module per driver - ie a radeon.o, but not a drm_core.o + drm_radeon.o combo. He hasn't seen alsa or usb then...:) -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New Developer
I, personally, found it useful to install the sources and incrementally turn on and/or add new diagnostic type print statements to gain an understanding of top to bottom control and information flow in a simple operation such as drawing a single triangle. gdb can also be useful in just gaining an understanding of whats going on. Because of the extensive use of function pointers, its not always easy to follow flow by simply perusing the source files, but to me understanding basic bindings, control flow and information flow is an essential prerequisite to being able to contribute. Mike ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SGI transfers 3D graphics patents to MS
Conversely, if MS considers OpenGL to be dead and buried, period, it seems that Bill would be bit silly to want to spend $62.5 to become the owner of said dead + buried technology!! Mike Gareth Hughes wrote: Philip Brown wrote: but I would say that microsoft DOES want to kill OpenGL, since then they would control the only useful 3D API. It's all about creating monopolies. (so he can build hotels?) Allen's original statement made the point that MS considers OpenGL to be dead and buried, period. They've fought that battle, and in their mind, won. If this is the case, suggesting MS is out buying patents to kill off the DRI seems a bit silly... -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Intel 860 AGP bridge Support
We are presently acquiring a rather large cluster to build a distributed rendering system that will include some DRI related components. Some vendors responding to our bid have suggested replacing the specified 850 with the newer 860. Can anyone tell me if the existing DRI components are likely to work now (or soon) with the 860. thanks much, Mike James M. Westall Professor of Computer Science Clemson University Clemson SC 29634 0974 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 questions
I spent an incredibly frustrating 4 weeks trying to get the DRI to work with r128 and g400 cards on Dell precision workstation only to find that my problem was precisely because bus mastering was NOT enabled on boot! As soon as I fixed that everything worked fine. Apparently different BIOSes WILL leave the card in different states after boot. Mike ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NVidia Driver Source
The NV source is their kernel driver. This basic function of this routine is to manage DMA transfers of buffers full of graphics commands to the board. This is a very small piece of code that exposes almost nothing of the architecture of the graphics engine. The code that actually builds the buffers full of graphics commands is binary only (and resides in the NVIDIA_GLX stuff). So from any reasonable perspective NV is closed source. Nevertheless, I concur with you that what they provide works well. I have r128, g400, and gf2's in my lab.. and a gf2 on my desk. Mike Johannes Prix wrote: Dear DRI developers, I read in the FAQ, that NVidia provide their own binary closed source drivers. Yet visiting the Nvidia homepage driver section I find, that there are not only binary drivers for several distributions, but also a source rpm and a source tarball for those interested. Actually I used this source and the explicit and very details compilation and troubleshooting information there to install the driver on my system. It compiled and works well. Have I misunderstood the concept of closed source or is this perhaps valuable and sufficient information for the DRI project? Has there been a change in the attitude of NVidia? Perhaps someone could change those lines in the FAQ, for NVidia has in my opinion done great work. Thanks a lot if anyone has the time to answer this mail. Johannes Prix, Graz. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r128 module in linux kernel 2.4.6
Thilo, You make it sound as though you propose an easy and obvious solution with no adverse side-effects. Such is not the case. You are implicitly assuming a compatibility model in which any newer version of r128.o is GUARANTEED to work with any older version of the DRI. In ideal world that would be an ideal objective. In the real world, that is an unrealistic objective given rate at which the DRI code base has been evolving. After having fought (and lost) many battles with DRI and kernel installs (but now having a number of working installs), it is my feeling that it would be preferable to REMOVE the kernel drivers from the kernel source, thus making them module-only, and distribute them with XFree and/or the DRI-CVS. In that way, a person doing a complete build of X or DRI will end up with a compatible set of components and a person doing a kernel upgrade need only rebuild the kernel driver module associated with the compatible X/DRI distribution from source. At some point in the future things may stabilize to the point that your proposal becomes feasible, but I don't think we are quite there yet. Mike (not speaking for DRI developers) Westall Thilo Kopp wrote: to: [EMAIL PROTECTED] Dear Sirs: My notebook (Dell C800 Latitude) has a built-in RAGE MOBILITY 128 AGP 4X graphics card. The chiptype is M4 AGP4X. The corresponding kernel module is the r128.o which also enables DRI. The following setup works perfectly fine --- including DRI: kernel 2.4.3 XFree86_4.1.0 r128.ofrom http://dri.sourceforge.net/ compiled in May (it is necessary to replace the r128 module from the kernel module compilation by the r128 of the DRI-project!!!) It would now be reasonable that one could use a working r128 module with a newer kernel release. However, www.kernel.org is still implementing an old r128 module --- they obviously don't know that their module is outdated. I just tried it with kernel release 2.4.6, and the r128 module will not be loaded! : [drm] failed to load kernel module r128 (II) R128(0): [drm] drmOpen failed (EE) R128(0): [dri] DRIScreenInit failed. Disabling DRI. On the other hand, you can't replace the kernel module by the one which is working so nicely with kernel 2.4.3 because, if you would do so, the module dependencies were not correct with kernel 2.4.6 (try: /sbin/depmod and, of course, you will get depmod: *** Unresolved symbols in /lib/modules/2.4.6/kernel/drivers/char/drm/r128.o and /sbin/modprobe will not load the module which was not compiled for kernel 2.4.6). So I would like to ask the people from the DRI-project to make their r128 module available for the coming official kernel releases. Thank you! Sincerely yours, Thilo Kopp e-mail: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] What is the current state of acceleration support for Ati Mobility M4 (and other questions)?
The r128 support worked fine for us (after the usual install miseries) on an Inspiron with a Rage Mobility M3 AGP2x which we acquired about 10 months ago.. don't know about the M4 though. Mike 1) OK, I am still confused. Can someone please tell me is the DRI support working for the above-mentioned video card or not? ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI depth info readback problems
Thanks, Brian.. It turned out that the grad-student who was running those tests had inadvertently consigned himself to dll-hell via an ill considered LD_LIBRARY_PATH env variable on the r128 system. When that was corrected the r128 seems to work OK. We still can't get the mga to do right, but I guess at least our status is now in-sync with what you've experienced. Mike ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Synchronize with vertical retrace.
On the Glint TX/MX, PermediaN families, this was trivial. They have a SuspendUntilFrameBlank command whose operand in the new location of the frame buffer (for double buffering purposes). Hence you just put that at the end of each rendered frame. We always used that religiously for fear of introducing perceptible visual artifacts. (Our stuff used page flipping). However, I have been (pleasantly) surprised to see in the DRI that the present mode of just slap the data in there is for the most part free of flickers and tears. Mike ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
