Re: [Dri-devel] Mach64 developers
El Mar 25 Sep 2001 07:27, escribiste: On Sun, 23 Sep 2001, Manuel Teira wrote: Perhaps we should work with the latest DRI trunk. Do you think it worth the effort? It seems that most of the changes I noticed have been in the drivers for the newer cards, but I haven't really looked at it that closely at this point. I'm certainly no authority on this, I'm still trying to comprehend everything. ;) A logical analysis: The reset engine code is ORing the BUS_CNTL with 0x00a0, right? But we are suspecting that the component 0x0080 could be read only, and after looking at the code and the defines, it seems that this bit is redefined for the newer cards. Well, if the bit were read-only, the DRI_INFO for that register could learn us something. In my laptop, the BUS_CNTL before and after the DMA tests is always: BUS_CNTL = 0x7b3fa001 As you can see, the 0x0080 is not set, and the 0x0020 is set. Perhaps this is meaning that this bit is read-only and, so, the supposed obsoleted BUS_LAT16X ? What value is holding your BUS_CNTL ? I get 0x7b3fa101 before the test, which is the same except that bit 8 (reserved) is set, and after the DMA test (with the new code that resets the engine) I get 0x7b3fa141 -- BUS_MASTER_DIS is set by the reset code. Yes, excuse me. I'm getting 0x7b3fa041 after the test. Anyway, your results match my suposition that BUS_LAT16X is still present. Regards. -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
El Dom 23 Sep 2001 04:50, escribiste: According to the register ref. (p.4-26), GB means BGA package, AGP: both 1x and 2x). I have an LT Pro, which has LB in the device ID. This is in the CFG_CHIP_TYPE in CONFIG_CHIP_ID. There's also a class, foundry ID, and major/minor numbers in CONFIG_CHIP_ID. At any rate, I just looked at the dri trunk and it looks like there was a change here. The 'else' (mentioned in my previous mail) is now: else if (Chip ATI_CHIP_264VT4) I checked, and all other references to these regs in the code work the same way, so if the code is correct it seems that: BUS_FIFO_ERR_INT_EN, BUS_FIFO_ERR_INT are used for chips ATI_CHIP_264VTB BUS_HOST_ERR_INT_EN, BUS_HOST_ERR_INT are used for chips ATI_CHIP_264VT4 Perhaps we should work with the latest DRI trunk. Do you think it worth the effort? A logical analysis: The reset engine code is ORing the BUS_CNTL with 0x00a0, right? But we are suspecting that the component 0x0080 could be read only, and after looking at the code and the defines, it seems that this bit is redefined for the newer cards. Well, if the bit were read-only, the DRI_INFO for that register could learn us something. In my laptop, the BUS_CNTL before and after the DMA tests is always: BUS_CNTL = 0x7b3fa001 As you can see, the 0x0080 is not set, and the 0x0020 is set. Perhaps this is meaning that this bit is read-only and, so, the supposed obsoleted BUS_LAT16X ? What value is holding your BUS_CNTL ? -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
Hi guys!
I've had lot of other things to do in the past weeks so I couldn't work
on mach64. I've still problems to compile the trunk with Manuel's
patches. I haven't had time to track this down, so I decided to post my
changes of mach64_dma.c which I have made in my copy of the
mach64-branch. There it compiles well. The GUI-master isn't performed
though, but I rewrote the reset_engine function according to the
programmer's guide and I call it if the idle test after the transfer
failed. So hardware doesn't lock on my machine and I can start X where
glxinfo tells me that I'm have hardware based DRI but gears locks my
machine so that I have to reboot vie ssh.
It is possible, that the mach64_dma.c doesn't compile because I couldn't
test it. If something fails please report to me; there may be cut and
paste errors.
--Andreas Karrenbauer
/* mach64_dma.c -- DMA support for mach64 (Rage Pro) driver -*- linux-c -*-
* Created: Sun Dec 03 19:20:26 2000 by [EMAIL PROTECTED]
*
* Copyright 2000 Gareth Hughes
* All Rights Reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the Software),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* GARETH HUGHES BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
* IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*
* Authors:
* Gareth Hughes [EMAIL PROTECTED]
*/
#include mach64.h
#include drmP.h
#include mach64_drv.h
#include linux/interrupt.h/* For task queue support */
#include linux/delay.h
static unsigned long mach64_alloc_page( void )
{
unsigned long address;
address = __get_free_page( GFP_KERNEL );
if ( address == 0UL ) {
return 0;
}
atomic_inc( virt_to_page(address)-count );
set_bit( PG_reserved, virt_to_page(address)-flags );
return address;
}
static void mach64_free_page( unsigned long address )
{
if ( !address ) return;
atomic_dec( virt_to_page(address)-count );
clear_bit( PG_reserved, virt_to_page(address)-flags );
free_page( address );
return;
}
/*
* Engine control
*/
int mach64_do_wait_for_fifo( drm_mach64_private_t *dev_priv, int entries )
{
int slots = 0, i;
for ( i = 0 ; i dev_priv-usec_timeout ; i++ ) {
slots = (MACH64_READ( MACH64_FIFO_STAT )
MACH64_FIFO_SLOT_MASK);
if ( slots = (0x8000 entries) ) return 0;
udelay( 1 );
}
DRM_ERROR( failed! slots=%d entries=%d\n, slots, entries );
return -EBUSY;
}
int mach64_do_wait_for_idle( drm_mach64_private_t *dev_priv )
{
int i, ret;
ret = mach64_do_wait_for_fifo( dev_priv, 16 );
if ( ret 0 ) return ret;
for ( i = 0 ; i dev_priv-usec_timeout ; i++ ) {
if ( !(MACH64_READ( MACH64_GUI_STAT ) MACH64_GUI_ACTIVE) ) {
return 0;
}
udelay( 1 );
}
DRM_ERROR( failed! GUI_STAT=0x%08x\n,
MACH64_READ( MACH64_GUI_STAT ) );
return -EBUSY;
}
int mach64_do_engine_reset( drm_mach64_private_t *dev_priv )
{
u32 bus_cntl, gen_test_cntl;
/* Kill off any outstanding DMA transfers.
*/
bus_cntl = MACH64_READ( MACH64_BUS_CNTL );
MACH64_WRITE( MACH64_BUS_CNTL,
bus_cntl | MACH64_BUS_MASTER_DIS );
/* Reset the GUI engine (high to low transition).
*/
gen_test_cntl = MACH64_READ( MACH64_GEN_TEST_CNTL );
MACH64_WRITE( MACH64_GEN_TEST_CNTL,
gen_test_cntl ~MACH64_GUI_ENGINE_ENABLE );
/* Enable the GUI engine
*/
gen_test_cntl = MACH64_READ( MACH64_GEN_TEST_CNTL );
MACH64_WRITE( MACH64_GEN_TEST_CNTL,
gen_test_cntl | MACH64_GUI_ENGINE_ENABLE );
/* ensure engine is not locked up by clearing any FIFO or HOST errors
*/
bus_cntl = MACH64_READ( MACH64_BUS_CNTL );
MACH64_WRITE( MACH64_BUS_CNTL, bus_cntl | 0x00a0 );
Re: [Dri-devel] Mach64 developers
El Sáb 22 Sep 2001 14:54, escribiste: Hi guys! I've had lot of other things to do in the past weeks so I couldn't work on mach64. I've still problems to compile the trunk with Manuel's patches. I haven't had time to track this down, so I decided to post my changes of mach64_dma.c which I have made in my copy of the mach64-branch. There it compiles well. The GUI-master isn't performed though, but I rewrote the reset_engine function according to the programmer's guide and I call it if the idle test after the transfer failed. So hardware doesn't lock on my machine and I can start X where glxinfo tells me that I'm have hardware based DRI but gears locks my machine so that I have to reboot vie ssh. It's nice to hear about you again. I'll test the changes you've made on my machine ASAP. BTW, I've take a fast look about the way you are allocating the memory for the test: struct pci_pool *pool; void *cpu_addr_table, *cpu_addr_data; void *cpu_addr_table, *cpu_addr_data; pool = pci_pool_create( mach64, NULL, 0x4000, 0x4000, 0x4000, SLAB_ATOMIC ); cpu_addr_table = pci_pool_alloc( pool, SLAB_ATOMIC, table_addr ); cpu_addr_data = pci_pool_alloc( pool, SLAB_ATOMIC, data_addr ); What alignment are you getting on this way? Could we select a diferent alignment using this kind of memory alloc? It is possible, that the mach64_dma.c doesn't compile because I couldn't test it. If something fails please report to me; there may be cut and paste errors. I'll try soon. -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
Manuel Teira wrote: It's nice to hear about you again. I'll test the changes you've made on my machine ASAP. BTW, I've take a fast look about the way you are allocating the memory for the test: struct pci_pool *pool; void *cpu_addr_table, *cpu_addr_data; void *cpu_addr_table, *cpu_addr_data; pool = pci_pool_create( mach64, NULL, 0x4000, 0x4000, 0x4000, SLAB_ATOMIC ); cpu_addr_table = pci_pool_alloc( pool, SLAB_ATOMIC, table_addr ); cpu_addr_data = pci_pool_alloc( pool, SLAB_ATOMIC, data_addr ); What alignment are you getting on this way? Could we select a diferent alignment using this kind of memory alloc? have a look at kernel-source-dir/Documentation/DMA-mapping.txt there's the explaination about this API. I think we should use this if anybody hasn't any objections. pci_pool_create is specified: pool = pci_pool_create( name, dev, size, align, alloc, flags ); in this case a 16kB buffer aligned to 16kB boundry (16384 = 0x4000) please tell me status of your Xserver after starting. does it start up? does the hardware lock? are you able to run gears without locking? what does glxinfo tell you? I would like to compare to my status in order to have the same working ground. Furthermore I suggest to drop the GUI master issue at the moment (it isn't used in the driver right now or am I wrong? and therefore it is just a performance issue) If your gears locks too, then I would first track this down. Debuging this is very hard because I have to boot after every try. --Andreas Karrenbauer ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
El Sáb 22 Sep 2001 17:03, escribiste: Manuel Teira wrote: have a look at kernel-source-dir/Documentation/DMA-mapping.txt OK. Thanks for the help. there's the explaination about this API. I think we should use this if anybody hasn't any objections. pci_pool_create is specified: pool = pci_pool_create( name, dev, size, align, alloc, flags ); in this case a 16kB buffer aligned to 16kB boundry (16384 = 0x4000) I think it's fine. please tell me status of your Xserver after starting. does it start up? does the hardware lock? are you able to run gears without locking? what does glxinfo tell you? To say you the truth, I haven't been trying to test the XServer with any client. I was just starting it, stopping it (using Ctrl+Alt+BackSpace) and looking at the /var/log/kern.log to see the DMA test status. Now, I've started the X with this command: xinit -- /usr/X11DRI/bin/XFree86 that's the location of my testing XFree server. After that, my WindowManager (KDE) started. I tried the glxinfo after setting the LD_LIBRARY_PATH to : LD_LIBRARY_PATH=/usr/X11DRI/lib and the result is: 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: Gareth Hughes OpenGL renderer string: Mesa DRI Mach64 20001218 [Rage Pro] x86/SSE OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_func_separate, 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_object, 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 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 -- 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x29 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow Then, I closed my eyes and fired 'gears'. Well, it didn't lock my machine, the gears window only contained garbage, but the program was running, and saying: 1786 frames in 5.002 seconds = 357.057 FPS 1736 frames in 5 seconds = 347.2 FPS Well, I tried it several times, all the time with the same result. On other terminal (without the LD_LIBRARY_PATH variable set) I tried gears, and it runs normally (without 2D or 3D acceleration) and getting around 120 FPS. I would like to compare to my status in order to have the same working ground. Furthermore I suggest to drop the GUI master issue at the moment (it isn't used in the driver right now or am I wrong? and therefore it is just a performance issue) I suppose it's not used, because it never worked, while Gareth code was usable (at least with one of my laptops). If your gears locks too, then I would first track this down. Debuging this is very hard because I have to boot after every try. If you want any log from my computer, please tell me. I'm sending you the mach64_dma.c I'm using (it's just a merge between yours and mine). Perhaps you have to add some extra define to mach64_drv.h to use it, could be: # define MACH64_BUS_APER_REG_DIS (1 4) or # define MACH64_BUS_EXT_REG_EN(1 27) -- Manuel Teira /* mach64_dma.c -- DMA support for mach64 (Rage Pro) driver -*- linux-c -*- * Created: Sun Dec 03 19:20:26 2000 by [EMAIL PROTECTED] * * Copyright 2000 Gareth Hughes * All Rights Reserved. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the Software), * to deal in the Software without restriction, including without limitation * the rights to use, copy, modify, merge, publish, distribute, sublicense, * and/or sell copies of the Software, and to permit persons to whom the
Re: [Dri-devel] Mach64 developers
El Sáb 22 Sep 2001 18:12, escribiste: Manuel Teira wrote: Then, I closed my eyes and fired 'gears'. Well, it didn't lock my machine, the gears window only contained garbage, but the program was running, and saying: 1786 frames in 5.002 seconds = 357.057 FPS 1736 frames in 5 seconds = 347.2 FPS Well, I tried it several times, all the time with the same result. On other terminal (without the LD_LIBRARY_PATH variable set) I tried gears, and it runs normally (without 2D or 3D acceleration) and getting around 120 FPS. well that's fine I get about the same values. I achieved ca. 350 fps one time and cannot reproduce. Well, I said that it's getting 347 FPS, but nothing is showing in the window, just garbage (and garbage that didn't looks like three wheels). so you are a step further than me. what kind of source are you using? the trunk or the branch? I'm using the XFree 4.1.0 trunk with my modifications, and the mach64_dma.c file I sent you today. Perhaps if I can overcome this compiling errors I have hw accelerated X, too. It would be great if you could do some testing with programs using 3D *AND* 2D and report whether something is wrong (like texture or things like that) When we have a running Xserver perhaps anybody with special connections to ATI could contact we the developers there and ask about some help why the GUI master doesn't work despite it is done as described in the programmer's guide. This only makes sense if we can exclude every other source of errors. The 2D acceleration is disabled in my Xserver (as in the Gareth's code (mach64 branch) ). Perhaps this is what is making your computer hang. If you want any log from my computer, please tell me. First I try to compile the trunk with the changes: for example, it starts at the creation of the Makefiles: at /lib/GL/mesa/src/drv/mach64 the created Makefile is corupt (missing seperator is reported and the Makefile itself is a mess) it's possible that it is easy to fix but I haven't had time to Perhaps your Imakefile is wrong. What codebase are you starting from? -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
Hi, This is re Andreas Karrenbauer's prob.. perhaps it's a bit off topic, but it might help... Have you tried logging in via SSH and killing off and starting X via that? I have had a fair degree of success restoring graphics mode that way (though text mode stays hosed). As I said, I don't know if it's relevant (or even safe, registers could change and not be restored), but so far as I can see it could really help with devel time. David Bronaugh ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
El Sáb 22 Sep 2001 19:08, escribiste: Manuel Teira wrote: El Sáb 22 Sep 2001 18:30, escribiste: You can pass an argument to isosurf to tell it to render only 100 triangles (isosurf -100) - another good option, and you can get it to render more by moving with the arrow keys. isosurf, where could I find it? Mesa demos directory, same place gears normally lives. see www.mesa3d.org. Keith I have had problems trying to compile the demos myself, so, I've extracted them from a binary package I've found. And now, the results: 1.-When the new bm_dma_test is called from the dma_init it fails as ever. Then, if I try to run the 'gears' demo, it hangs the machine. 2.-When the bm_dma_test is called from the dma_cleanout, the gears demo runs, showing only garbage on the screen. So, it seems that we should blame the DMA test for the locks. 3.-Finally, and in the same environment than (2), I've tried to run the isosurf demo. Against all the bets, it worked. Well, it's able to render the figures as good as in software mode (with the software GL library), but with some problems: - There's garbage in the background of the window. - The window is not cleaned for each frame, so, all the shapes are mixed on the screen after some key strokes. Now, we need somebody with knowledge about the internals to look for the reason of this behaviour. Perhaps something related with buffer swapping? -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
On Sat, 22 Sep 2001, Manuel Teira wrote: El Sáb 22 Sep 2001 19:08, escribiste: Manuel Teira wrote: El Sáb 22 Sep 2001 18:30, escribiste: You can pass an argument to isosurf to tell it to render only 100 triangles (isosurf -100) - another good option, and you can get it to render more by moving with the arrow keys. isosurf, where could I find it? Mesa demos directory, same place gears normally lives. see www.mesa3d.org. Keith I have had problems trying to compile the demos myself, so, I've extracted them from a binary package I've found. And now, the results: 1.-When the new bm_dma_test is called from the dma_init it fails as ever. Then, if I try to run the 'gears' demo, it hangs the machine. 2.-When the bm_dma_test is called from the dma_cleanout, the gears demo runs, showing only garbage on the screen. So, it seems that we should blame the DMA test for the locks. 3.-Finally, and in the same environment than (2), I've tried to run the isosurf demo. Against all the bets, it worked. Well, it's able to render the figures as good as in software mode (with the software GL library), but with some problems: - There's garbage in the background of the window. - The window is not cleaned for each frame, so, all the shapes are mixed on the screen after some key strokes. I've tried out the changes and I got the same results with glxheads. The garbage in the background for me is part of the KDE splash screen and part of my desktop background. Again, the shapes are drawn and rotated, but the window is not cleared for each frame. I'm a bit confused about something in the engine reset code. The sample engine reset code in the programmer's guide mentions setting BUS_FIFO_ERR_ACK and BUS_HOST_ERR_ACK in BUS_CNTL (0x00a0), but the register guide shows these bits as BUS_MSTR_RD_LINE and LAT16X respectively, with LAT16X being read-only. The 2D driver (atiregs.h) has these defines: #define BUS_FIFO_ERR_INT_EN 0x0010ul #define BUS_MSTR_RD_MULT0x0010ul/* VTB/GTB/LT */ #define BUS_FIFO_ERR_INT0x0020ul #define BUS_MSTR_RD_LINE0x0020ul/* VTB/GTB/LT */ #define BUS_HOST_ERR_INT_EN 0x0040ul #define BUS_SUSPEND 0x0040ul/* GTPro */ #define BUS_HOST_ERR_INT0x0080ul #define BUS_LAT16X 0x0080ul/* GTPro */ ..and there is code like this in atiprobe.c: /* Make sure any Mach64 is not in some weird state */ bus_cntl = inr(BUS_CNTL); if (Chip ATI_CHIP_264VTB) outr(BUS_CNTL, (bus_cntl ~(BUS_HOST_ERR_INT_EN | BUS_FIFO_ERR_INT_EN)) | (BUS_HOST_ERR_INT | BUS_FIFO_ERR_INT)); else outr(BUS_CNTL, (bus_cntl ~BUS_HOST_ERR_INT_EN) | BUS_HOST_ERR_INT); Does anyone know what's going on here? -- Leif Delgass ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 developers
Hi all, I've looked at the documentation, and it's odd, it seems like nobody is mentioning the Mach64 GB. It might be this is simply named wrong in my bios, and it seems to run the same as other cards. Here's my PCI entry: pci bus 0x1 cardnum 0x00 function 0x: vendor 0x1002 device 0x4742 ATI Mach64 GB This is a All in Wonder model but this may all be irrelevant. Carl Busjahn Manuel Teira wrote: El Dom 23 Sep 2001 00:28, escribiste: On Sat, 22 Sep 2001, Manuel Teira wrote: El Sáb 22 Sep 2001 19:08, escribiste: And now, the results: 1.-When the new bm_dma_test is called from the dma_init it fails as ever. Then, if I try to run the 'gears' demo, it hangs the machine. 2.-When the bm_dma_test is called from the dma_cleanout, the gears demo runs, showing only garbage on the screen. So, it seems that we should blame the DMA test for the locks. 3.-Finally, and in the same environment than (2), I've tried to run the isosurf demo. Against all the bets, it worked. Well, it's able to render the figures as good as in software mode (with the software GL library), but with some problems: - There's garbage in the background of the window. - The window is not cleaned for each frame, so, all the shapes are mixed on the screen after some key strokes. I've tried out the changes and I got the same results with glxheads. The garbage in the background for me is part of the KDE splash screen and part of my desktop background. Again, the shapes are drawn and rotated, but the window is not cleared for each frame. Exactly the same I'm experimenting (part of the KDE splash screen). I'm a bit confused about something in the engine reset code. The sample engine reset code in the programmer's guide mentions setting BUS_FIFO_ERR_ACK and BUS_HOST_ERR_ACK in BUS_CNTL (0x00a0), but the register guide shows these bits as BUS_MSTR_RD_LINE and LAT16X respectively, with LAT16X being read-only. The 2D driver (atiregs.h) has these defines: #define BUS_FIFO_ERR_INT_EN 0x0010ul #define BUS_MSTR_RD_MULT0x0010ul/* VTB/GTB/LT */ #define BUS_FIFO_ERR_INT0x0020ul #define BUS_MSTR_RD_LINE0x0020ul/* VTB/GTB/LT */ #define BUS_HOST_ERR_INT_EN 0x0040ul #define BUS_SUSPEND 0x0040ul/* GTPro */ #define BUS_HOST_ERR_INT0x0080ul #define BUS_LAT16X 0x0080ul/* GTPro */ Yes, it's really weird. Comparing the Programmers Guide and the Register's Reference guide, I see the following: iow32(BUS_CNTL,(ior32(BUS_CNTL)|0x00a0)) and after reading the Register Reference Guide, 0x00a0=BUS_MSTR_RD_LINE | BUS_LAT16X while in the Programmers Guide, they are talking about setting: BUS_FIFO_ERR_ACK@BUS_CNTL and BUS_HOST_ERR_ACK@BUS_CNTL. It seems that the register bits have different meanings regarding the Card Model, as you can see in the define comments. Anyway, it's not clear for me: - GTPro. I assume, they're talking about a GT Model (Rage I, RageII, II+, IIC, Rage PRO). If we trust the Mach64 Programmers Guide, these models have 3D acceleration (3D RAGE) - VTB/GTB/LT. This is strange. Assuming they're talking about VT and GT models (but the GT model is the same as the GTPro). And what about the LT? Perhaps a RAGE LT-Pro (actually a LB/GM model). ..and there is code like this in atiprobe.c: /* Make sure any Mach64 is not in some weird state */ bus_cntl = inr(BUS_CNTL); if (Chip ATI_CHIP_264VTB) outr(BUS_CNTL, (bus_cntl ~(BUS_HOST_ERR_INT_EN | BUS_FIFO_ERR_INT_EN)) | (BUS_HOST_ERR_INT | BUS_FIFO_ERR_INT)); else outr(BUS_CNTL, (bus_cntl ~BUS_HOST_ERR_INT_EN) | BUS_HOST_ERR_INT); After reading this, I suppose that with GTPro they're talking about an older model than the VT, that is, a Mach64GX Family model (if Chip ATI_CHIP_264VTB) . And there's something wrong, assuming that the 'else' is for the GTPro cards, they are trying to set the BUS_LAT16X == BUS_HOST_ERR_INT, a read only bit in the BUS_CNTL register. Perhaps the Register Reference is not updated or have some bugs. I don't know. Could be a good idea to take a look at the XFree 3.x version to see how is it setting up the card, allowing Utah-GLX to work. Does anyone know what's going on here? ___ 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
