Re: [Dri-devel] [Announce] New mach64 snapshot
Please check the new package. Nothing really new, except that the things you noticed (should) have been fixed. I've run the installation uninstalltion process fine. I didn't have time to really start X because it's pretty late here (as you can see by the build time). Just tried. The installation was really smooth. But running was bad enough. The screen got blank and I have to reboot the system remotely:((( In the XFree86.0.log: (II) ATI(0): [drm] installed DRM signal handler (II) ATI(0): [DRI] installation complete Symbol drmMach64CleanupDMA from module /usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMach64InitDMA from module /usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved! Fatal server error: Caught signal 4. Server aborting When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED] Symbol drmMach64InitDMA from module /usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMach64CleanupDMA from module /usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved! FatalError re-entered, aborting Caught signal 11. Server aborting Any ideas? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 7500 lockup kludge-around
Michael wrote:
On Tue, Mar 12, 2002 at 04:53:43PM -0800, Keith Packard wrote:
On the radeon card, I'm also seeing problems with
other texturing -- translucency isn't working (translucent objects appear
opaque)
Thanks for the report. I'd seen that (in a different program) and
forgotten about it.
(A temp workaround is export RADEON_NO_VTXFMT=1)
At least 3 things here
a) _FPALPHA is never set, so it never sends alpha to the card.
Trivial fix (I think) to check ctx-Color.AlphaEnabled in
choose_vertex_format and set it appropriately?
b) ~/glut/demos/contrib/steam which has a toggle for transparent
reveals a subtler issue with CHOOSE_COLOR.
A typical path will go
neutral_Colorxx - choose_Colorxx - radeon_codegen or 'c' version
At some stage _mesa_restore_exec_vtxfmt will replace the neutral_Colorxx because
we aren't saving the second clobber in Swapped.
But CHOOSE_COLOR conditionally calls _mesa_install_exec_vtxfmt itself,
which does the above restore, so whereas typically we clobber a
TnlModule.Swapped function, it's possible for CHOOSE_COLOR to
restore neutral_xx just prior to us clobbering it and we're stuck
forever with SwapCount 0 and (in this case) radeon_Color4f_3f, even when the
vertex_format changes and we want radeon_Color4f_4f.
Could add a restore bool param to _mesa_install_exec_vtxfmt or a
new norestore version of the function?
Something like this might also work (re-loop through neutral to get another
opportunity to swap something in). I haven't tested this:
#define CHOOSE_COLOR(FN, FNTYPE, NR, MASK, ACTIVE, ARGS1, ARGS2 ) \
static void choose_##FN ARGS1 \
{ \
int key = vb.rmesa-vertex_format (MASK|ACTIVE); \
struct dynfn *dfn; \
GLcontext *ctx = vb.context; \
\
if (vb.rmesa-vertex_format ACTIVE_PKCOLOR) { \
ctx-Exec-FN = radeon_##FN##_ub; \
}\
else if ((vb.rmesa-vertex_format \
(ACTIVE_FPCOLOR|ACTIVE_FPALPHA)) == ACTIVE_FPCOLOR) { \
\
if (vb.installed_color_3f_sz != NR) { \
vb.installed_color_3f_sz = NR; \
if (NR == 3) ctx-Current.Color[3] = 1.0; \
radeon_copy_to_current( ctx ); \
_mesa_install_exec_vtxfmt( ctx, vb.vtxfmt ); \
ctx-Exec-FN ARGS2; \
return;\
} \
\
ctx-Exec-FN = radeon_##FN##_3f; \
}\
else { \
ctx-Exec-FN = radeon_##FN##_4f; \
}\
\
\
dfn = lookup( vb.dfn_cache.FN, key ); \
if (!dfn) dfn = vb.codegen.FN( vb, key ); \
\
if (!dfn) { \
if (RADEON_DEBUG DEBUG_CODEGEN) \
fprintf(stderr, %s -- codegen version\n, __FUNCTION__ ); \
ctx-Exec-FN = (FNTYPE)dfn-code;\
}\
else if (RADEON_DEBUG DEBUG_CODEGEN) \
fprintf(stderr, %s -- 'c' version\n, __FUNCTION__ ); \
\
ctx-Driver.NeedFlush |= FLUSH_UPDATE_CURRENT; \
ctx-Exec-FN ARGS2; \
}
Keith
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 7500 lockup kludge-around
A slightly less buggy version (still untested). My incoming email seems to be
hosed...
#define CHOOSE_COLOR(FN, FNTYPE, NR, MASK, ACTIVE, ARGS1, ARGS2 ) \
static void choose_##FN ARGS1 \
{ \
int key = vb.rmesa-vertex_format (MASK|ACTIVE); \
struct dynfn *dfn; \
GLcontext *ctx = vb.context; \
\
if (vb.rmesa-vertex_format ACTIVE_PKCOLOR) { \
ctx-Exec-FN = radeon_##FN##_ub; \
}\
else if ((vb.rmesa-vertex_format \
(ACTIVE_FPCOLOR|ACTIVE_FPALPHA)) == ACTIVE_FPCOLOR) { \
\
if (vb.installed_color_3f_sz != NR) { \
vb.installed_color_3f_sz = NR; \
radeon_copy_to_current( ctx ); \
if (NR == 3) ctx-Current.Color[3] = 1.0; \
_mesa_install_exec_vtxfmt( ctx, vb.vtxfmt ); \
ctx-Exec-FN ARGS2; \
return;\
} \
\
ctx-Exec-FN = radeon_##FN##_3f; \
}\
else { \
ctx-Exec-FN = radeon_##FN##_4f; \
}\
\
\
dfn = lookup( vb.dfn_cache.FN, key ); \
if (!dfn) dfn = vb.codegen.FN( vb, key ); \
\
if (dfn) { \
if (RADEON_DEBUG DEBUG_CODEGEN) \
fprintf(stderr, %s -- codegen version\n, __FUNCTION__ ); \
ctx-Exec-FN = (FNTYPE)dfn-code;\
}\
else if (RADEON_DEBUG DEBUG_CODEGEN) \
fprintf(stderr, %s -- 'c' version\n, __FUNCTION__ ); \
\
ctx-Driver.NeedFlush |= FLUSH_UPDATE_CURRENT; \
ctx-Exec-FN ARGS2; \
}
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Bug 529551 resolved
Just disable VERTEX LIGHTING under the Graphics tab in Settings for Tribes 2 enables the shiny environment map. Don't know if enabling Vertex Lighting is required, a enhancement to Graphics or simply away to disable certain effects. Anyone with knowledge on this issue could comment. Thanks, Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 7500 lockup kludge-around
Around 12 o'clock on Mar 14, Keith Whitwell wrote: A slightly less buggy version (still untested). My incoming email seems to be hosed... I haven't locked this up with test involving textures. I still have a reliable lockup when disabling textures in bzflag which is resolved with a clean reboot (no reset button required). And, GL_LUMINANCE_ALPHA textures are broken as well -- the alpha channel is bilinear interpolated but the luminance channel is interpolated in Y but nearest in X. Makes text rather interesting to read (vertical elements end up black). See a sample of the fun text at: http://keithp.com/~keithp/download/bzflag.png Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64 binaries: do work! Was: do not work...
The latest snapshot, http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/bleeding-edge/mach64-20020314-1601-i386-Linux.tar.bz2 works. I've checked it myself. The problem was libdrm.a which is not as device independent as thought. It has some interface functions which in the case of mach64 are new and not available in the XFree86 4.x releases. I've changed install.sh to be more permissive regarding missing files in the package, i.e., just backup/install files that are included in the package. The result is that a single install.sh can be used to install/uninstall either a complete or a minimal package. I also noticed that the snapshots of mach64-0-0-3-branch don't work on Xfree86 4.1.0, since the 2D driver ABI changed between the releases. I suppose it's the same for all driver snapshots taken from the trunk, althought that was not my previous impression. Sergey, please test once more. If everything is okay, I'll start uploading the mach64 snapshots to the DRI website as well. (And put a README describing the current limitations of mach64) Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do work! Was: do not work...
Le 14 Mar 2002 17:07:47 + Jose Fonseca [EMAIL PROTECTED] a écrit: The latest snapshot, http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/bleeding-edge/mach64-20020314-1601-i386-Linux.tar.bz2 works. I've checked it myself. The problem was libdrm.a which is not as device independent as thought. It has some interface functions which in the case of mach64 are new and not available in the XFree86 4.x releases. I've changed install.sh to be more permissive regarding missing files in the package, i.e., just backup/install files that are included in the package. The result is that a single install.sh can be used to install/uninstall either a complete or a minimal package. I also noticed that the snapshots of mach64-0-0-3-branch don't work on Xfree86 4.1.0, since the 2D driver ABI changed between the releases. I suppose it's the same for all driver snapshots taken from the trunk, althought that was not my previous impression. Sergey, please test once more. If everything is okay, I'll start uploading the mach64 snapshots to the DRI website as well. (And put a README describing the current limitations of mach64) Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel I tested it and it works almost perfectly: the modprobe mach64 failed, not finding the module. A simple depmod -a did the work, dont know if it's specific to my config. Glxgears and Tuxracer run quite well, but I couldn't explore the possibilities, since my laptop was needed as a dvd player (thanks to Keith for the mach64 TV-out!) It's quite easy to switch back to the old config (and get xv back...), but what are exactly the difficulties that you run into when trying to enable both 3D and 2D acceleration? (according to gatos, there's no problem with production dri drivers). -- Bernard Cafarelli alias Voyageur ICQ:66024647 msg03473/pgp0.pgp Description: PGP signature
Re: [Dri-devel] mach64 binaries: do work! Was: do not work...
The latest snapshot, http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/bleeding-edge/mach64-20020314-1601-i386-Linux.tar.bz2 works. I've checked it myself. I checked it too. No installation problems noticed. Everything went smoothly. glxgears works on 248fps. The problem was libdrm.a which is not as device independent as thought. :( Well, anyway it is not as big as libGL. It has some interface functions which in the case of mach64 are new and not available in the XFree86 4.x releases. What's good is that now we know it - so next releases will be more smooth. I also noticed that the snapshots of mach64-0-0-3-branch don't work on Xfree86 4.1.0, since the 2D driver ABI changed between the releases. I suppose it's the same for all driver snapshots taken from the trunk, althought that was not my previous impression. What about compatibility with 4.0 (or even 3.3)? I guess for brave testers like me even compatibility with 4.2 is enough... Sergey, please test once more. If everything is okay, I'll start uploading the mach64 snapshots to the DRI website as well. (And put a README describing the current limitations of mach64) I'd say I have no objections:) It is very cool when someone asks me permission to upload something (especially - something I did not develop:) Regards, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do work! Was: do not work...
On 2002.03.14 20:30 Bernard Cafarelli wrote: Le 14 Mar 2002 17:07:47 + ... I tested it and it works almost perfectly: the modprobe mach64 failed, not finding the module. A simple depmod -a did the work, dont know if it's specific to my config. Glxgears and Tuxracer run quite well, but I couldn't explore the possibilities, since my laptop was needed as a dvd player (thanks to Keith for the mach64 TV-out!) It's quite easy to switch back to the old config (and get xv back...), but what are exactly the difficulties that you run into when trying to enable both 3D and 2D acceleration? (according to gatos, there's no problem with production dri drivers). There is no special difficulty, just work to be done. In fact, on the current mach64 driver, work to do is its most outstanding feature! So until the developers decide to that this is more important than enhancing the 3D backend, or some newbie decides to volunteer to do this job, it will remain work to be done for quite some time... -- Bernard Cafarelli alias Voyageur ICQ:66024647 Regards, José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: dri trouble
Thanks, that's what I needed to know. One last question - would you know whether Radeon AGP has a restriction of not being able to DMA into non-AGP memory ? I am providing a table with physical addresses and all, but transfers below 0x400 fail - and this is the value written in CP_RB_BASE, which also coincides with statement from agpgart that only 439mb out of 512 are available for agp memory. Is there a way to query agpgart about which memory is agp without acquiring it ? Are you sure your radeon memory controller hasn't anything else mapped to below 0x400 ? (like the frame buffer). AFAIK, Radeon will do perfectly normal bus master from any address not colliding with either MC_FB_LOCATION or MC_AGP_LOCATION. That's a reason why I beleive we should hack the driver to always remap MC_FB_LOCATION to match the bus address of the frame buffer as seen from the PCI. Currently, at least on pmacs, we set MC_FB_LOCATION so that the framebuffer is at address 0 in card space. If we also take care of putting the AGP aperture in such a location where it won't collide with RAM, the entire machine memory will be available to normal bus master. I've done some experiments moving MC_FB_LOCATION around on my tipb (Radeon M6) but mostly obtained hard card lockups, I beleive that value can't just be moved alone. We must obviously move DISPLAY_BASE_ADDR (and it's equivalent for CRTC2), some surface regs, and probably a few others. The doc isn't always clear about what registers are absolute addresses in card space, and what are offsets relative to MC_FB_LOCATION. Ben. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
