Re: Fw: Re: [Dri-devel] savage-2-0-0 test notes
--- Marco Strack <[EMAIL PROTECTED]> wrote: > Begin forwarded message: > > Date: Fri, 27 Feb 2004 11:59:22 -0600 > From: Steve Holland <[EMAIL PROTECTED]> > To: Felix Khling <[EMAIL PROTECTED]> > Subject: Re: [Dri-devel] savage-2-0-0 test notes > > > I tested it with a fresh copy from the trunk (effective > tuesday), > >> > >> > >> and > >> > have the same problems. > Here are some PNG's of the results from drawpix: > 16 bit display, drawing to back buffer: > http://69.5.151.193/~sdh4/drawpix16bit.png > drawing to front buffer: > http://69.5.151.193/~sdh4/drawpix16bitfrontbuffer.png > 24 bit display drawing to back buffer: > http://69.5.151.193/~sdh4/drawpix24bit.png > (24 bit display drawing to front buffer was similar to > 16->front > buffer) > > I also noticed problems when switching video modes on a 24 bit > display. For example, running tuxracer would get the display > parameters > >> > >> > >> wrong, > >> > leading to an incomprehensible display (even after quitting). > Thanks, Steve > > > > The code i'm running is also about 2-3 days old. I've got the same > Hardware (T23 - supersavage IX/SDR). > > What he means with corruption occurs when changing the display mode > "on-the-fly". Then the screen is corrupted. Switching back to the old > > resolution normalizes the screen again. > > This won't happen when starting initialy with the new setting. So > setting XF86Config to a new res and restart X everything is fine. > > > > Acceleration stuff : > > -only works in 16 bpp (2d/3d) > -in 24bpp there is no 2d nor any 3d accelleration. > -2D accell worked with tims driver on 24bpp. regarding the 24 bpp stuff. I'm not sure why that isn't working. once problem might be that the layout of the GBD might be wrong in the driver. I assumed it was like prosavage, but it might be like savage4 or m7. I just made an educated guess when I added the code. still if it works at 16 bit, it should work at 24 bit. if you want you can try changing the BD setup for supersavage in savage_accel.c and savage_dri.c. I can explain in more detail or provide a patch. it may also be that you just don't have enough mem in 24 bpp. Alex > > Tuxracer is still fine. But blender didn't change. The screen is > clean > but all fonts are corrupted. It seems to me that the fonts in blender > > are also gl, but that's just an assumption. > > > Besides that you did a _GREAT_ work, and the driver speeded up in the > > last 2-3 Months as gar as i can see. > With savage-2-0-0 i had about 270 fps in the beginning of working > dri-support for my chip. Than it got from 325 to 378. > And with the last code in the savage branch it reached 408. That > stayed > with the HEAD Branch since then. > > > > >regards marco > > __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com --- 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: Mach64 DRM module problems
Send your cards PCI ids to the list, Mike what card have you the DRM shouldn't load for any card that doesn't have the triangle engine really.. Dave. On Thu, 11 Mar 2004, Mike Mestnik wrote: > At first I thought it just might have been my system. In debuging the > problem I found ought that my chip dose not have triangle setup. It's not > likely that it will be supported by DRI. However the 2d driver gave me > xrendr support, this will help with TV out for me. > > As for the kmod if you post the errors to [EMAIL PROTECTED] > some one there might be able to help. > > --- Mikko Rauhala <[EMAIL PROTECTED]> wrote: > > Hi > > > > Just noticed that you were having about the same problems as me > > compiling the mach64 drm module for 2.6.3. I was just wondering if > > you've made any progress on it? I tried both the unofficial deb linked > > to by dri.sourceforge.net and the mach64-0-0-7-branch module directory, > > no go both ways. > > > > Thanks. > > > > -- > > Mikko Rauhala - [EMAIL PROTECTED] - http://www.iki.fi/mjr/> > > Transhumanist - WTA member - http://www.transhumanism.org/> > > Singularitarian - SIAI supporter - http://www.singinst.org/> > > > > > ATTACHMENT part 2 application/pgp-signature name=signature.asc > > > > __ > Do you Yahoo!? > Yahoo! Search - Find what you[92]re looking for faster > http://search.yahoo.com > > > --- > 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 > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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: Fw: Re: [Dri-devel] savage-2-0-0 test notes
On Thu, 11 Mar 2004 20:13:44 +0100 Marco Strack <[EMAIL PROTECTED]> wrote: [snip] > > Tuxracer is still fine. But blender didn't change. The screen is clean > but all fonts are corrupted. It seems to me that the fonts in blender > are also gl, but that's just an assumption. The font corruption should be solved since about last weekend. Can you try with current CVS. If it's still broken then maybe the SuperSavage uses a different tiling format for certain texel formats. Right now the driver assumes the same formats on SuperSavage as on ProSavage. If fonts are still broken then the current code makes it quite easy to experiment with tiling formats. You just have to change a few numbers in the beginning of savagetex.c. I could guide you through them so you can find the right numbers for the SuperSavage. > > > Besides that you did a _GREAT_ work, and the driver speeded up in the > last 2-3 Months as gar as i can see. > With savage-2-0-0 i had about 270 fps in the beginning of working > dri-support for my chip. Than it got from 325 to 378. > And with the last code in the savage branch it reached 408. That stayed > with the HEAD Branch since then. Not sure where that comes from. The 3D driver changes that may have had a positive effect on the performance were done on the Mesa trunk: - reorganized state management (I could hardly measure any speedup) - use smaller vertex formats where possible - more efficient texture upload (has no effect on glxgears) Did you change any compiler options? Changing optimizations from -O0 to -O3 gave me a good speed boost. > >regards marco Felix --- 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: Mach64 DRM module problems
At first I thought it just might have been my system. In debuging the problem I found ought that my chip dose not have triangle setup. It's not likely that it will be supported by DRI. However the 2d driver gave me xrendr support, this will help with TV out for me. As for the kmod if you post the errors to [EMAIL PROTECTED] some one there might be able to help. --- Mikko Rauhala <[EMAIL PROTECTED]> wrote: > Hi > > Just noticed that you were having about the same problems as me > compiling the mach64 drm module for 2.6.3. I was just wondering if > you've made any progress on it? I tried both the unofficial deb linked > to by dri.sourceforge.net and the mach64-0-0-7-branch module directory, > no go both ways. > > Thanks. > > -- > Mikko Rauhala - [EMAIL PROTECTED] - http://www.iki.fi/mjr/> > Transhumanist - WTA member - http://www.transhumanism.org/> > Singularitarian - SIAI supporter - http://www.singinst.org/> > > ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com --- 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] Help with X/Mesa segfault bug
I've found a problem in XFree86 4.3-4.4 that seems to involve mesa. I'm hoping someone familiar with the code could help look at it and see why the code is indexing off a null pointer. I've posted detailed stack traces to: http://bugs.xfree86.org/show_bug.cgi?id=512 And a summary to: http://sourceforge.net/tracker/index.php?func=detail&aid=912828&group_id=3&atid=13 This crash happens only when Xinerama is turned on and was not a problem under XFree86 4.2. I can do testing/debugging, but I'm lost and don't know where to look next. Can anyone on this list help? Kyle Bateman [EMAIL PROTECTED] --- 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: Fw: Re: [Dri-devel] savage-2-0-0 test notes
Begin forwarded message: Date: Fri, 27 Feb 2004 11:59:22 -0600 From: Steve Holland <[EMAIL PROTECTED]> To: Felix Khling <[EMAIL PROTECTED]> Subject: Re: [Dri-devel] savage-2-0-0 test notes I tested it with a fresh copy from the trunk (effective tuesday), >> >> >> and >> have the same problems. Here are some PNG's of the results from drawpix: 16 bit display, drawing to back buffer: http://69.5.151.193/~sdh4/drawpix16bit.png drawing to front buffer: http://69.5.151.193/~sdh4/drawpix16bitfrontbuffer.png 24 bit display drawing to back buffer: http://69.5.151.193/~sdh4/drawpix24bit.png (24 bit display drawing to front buffer was similar to 16->front buffer) I also noticed problems when switching video modes on a 24 bit display. For example, running tuxracer would get the display parameters >> >> >> wrong, >> leading to an incomprehensible display (even after quitting). Thanks, Steve The code i'm running is also about 2-3 days old. I've got the same Hardware (T23 - supersavage IX/SDR). What he means with corruption occurs when changing the display mode "on-the-fly". Then the screen is corrupted. Switching back to the old resolution normalizes the screen again. This won't happen when starting initialy with the new setting. So setting XF86Config to a new res and restart X everything is fine. Acceleration stuff : -only works in 16 bpp (2d/3d) -in 24bpp there is no 2d nor any 3d accelleration. -2D accell worked with tims driver on 24bpp. Tuxracer is still fine. But blender didn't change. The screen is clean but all fonts are corrupted. It seems to me that the fonts in blender are also gl, but that's just an assumption. Besides that you did a _GREAT_ work, and the driver speeded up in the last 2-3 Months as gar as i can see. With savage-2-0-0 i had about 270 fps in the beginning of working dri-support for my chip. Than it got from 325 to 378. And with the last code in the savage branch it reached 408. That stayed with the HEAD Branch since then. regards marco --- 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] SiS 305 segfaults, bug?
Hi I am using sis305 AGP card. I read all the documents. Including Thomas winiscoffer's sis page.To be specific the bios says"SiS 305 AGP 2X/4X True Color Graphics and Video Accelerator". I compiled sisfb inside the kernel and rest are modules I tried all these options kernel 2.6.3x xc of dri+mesa cvs and also xfree-4.4. when startx I get the following error in XFree86.0.log (**) SIS(0): Option "AGPSize" "32" (EE) SIS(0): [drm] Failed to acquire AGP, AGP disabled Though X works. And the log also shows (--) PCI:*(1:0:0) Silicon Integrated Systems [SiS] SiS300/305 PCI/AGP VGA Display Adapter rev 144, Mem @ 0xe800/27, 0xff8e/17, I/O @ 0xcc00/7, BIOS @ 0xff8d/16 lspci -v tells 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS300/305 PCI/AGP VGA Display Adapter (rev 90) (prog-if 00 [VGA]) Subsystem: Silicon Integrated Systems [SiS] SiS300/305 PCI/AGP VGA Display Adapter Flags: 66Mhz, medium devsel, IRQ 11 BIST result: 02 Memory at e800 (32-bit, prefetchable) [size=128M] Memory at ff8e (32-bit, non-prefetchable) [size=128K] I/O ports at cc00 [size=128] Expansion ROM at ff8d [disabled] [size=64K] Capabilities: [40] Power Management version 1 Capabilities: [50] AGP version 1.0 glxinfo says direct rendering "Yes" but glxgears and tuxracer shows wierd lines emanating from top left corner some more info in some instances your code compiled with dri+mesa cvs, glxinfo segfaults with the followiing error. #glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 0.1.0 sis (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/sis_dri.so drmOpenByBusid: Searching for BusID PCI:1:0:0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 Segmentation fault I feel that this is a bug. How do I correct it. I am giving more info below In other instances it gives the follwoing output name of display: :0.0 libGL: XF86DRIGetClientDriverName: 0.7.0 sis (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/sis_dri.so drmOpenByBusid: busid is PCI:1:0:0 drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports PCI:1:0:0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_make_current_read, GLX_SGIS_multisample client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating OpenGL vendor string: Eric Anholt OpenGL renderer string: Mesa DRI SiS 20030810 x86/MMX+/SSE2 OpenGL version string: 1.2 Mesa 5.0.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_IBM_rasterpos_clip, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGIS_texture_lod glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x22 16 tc 1 16 0 r . . 5 6 5 0 0 0 0 0 0 0 0 0 0 None 0x23 16 tc 1 16 0 r y . 5 6 5 0 0 0 0 0 0 0 0 0 0 None 0x24 16 tc 1 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x25 16 tc 1 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x26 16 tc 1 16 0 r . . 5 6 5 0 0 32 0 0 0 0 0 0 0 None 0x27 16 tc 1 16 0 r y . 5 6 5 0 0 32 0 0 0 0 0 0 0 None 0x28 16 tc 1 16 0 r . . 5 6 5 0 0 24 8 0 0 0 0 0 0 None 0x29 16 tc 1 16 0 r y . 5 6 5 0 0 24 8 0 0 0 0 0 0 None 0x2a 16 tc 1 16 0 r . . 5 6 5 0 0 0 0 16 16 16 16 0 0 None 0x2b 16 tc 1 16 0
Re: [Dri-devel] Mesa Linux solo and r100..
> Hi, > I've just tried getting a solo Mesa working on 2.4.25, latest DRM > from DRI CVS and top of tree Mesa on r100, > I got it working on 2.6.3 in the end, there must be some issue with the fb in 2.4.25 or something .. I'll start looking into it soon.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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
