Re: [Dri-devel] Mach64: BusMastering test seems to work
El Sáb 20 Oct 2001 02:49, Keith Whitwell escribió:
On Fri, 19 Oct 2001 17:24, Leif Delgass wrote:
Great work! I'll check this out soon.
Once we get DMA working for the 3D operations, I guess the next task is
to get the 2D acceleration routines synchronizing with the 3D ones so we
can reenable XAA, right? Also, it looks as if the AGP setup has not been
finished yet. At this point, atidri.c allocates 8M (hardcoded value, but
the agpgart module tells me I have a 64M AGP aperture) and maps 2M of it
for vertex buffers, but it never sets AGP_BASE or AGP_CNTL. There's
currently no allocation of an AGP region for textures. I'm seeing
problems with missing textures in the Quake 3 demo and some other GL
apps.
It's great to get past this hurdle, maybe we can get a new CVS branch
going soon!
Who would need cvs access? It's time this work got some support...
Well. I think we must put this work into CVS ASAP, so everybody could begin
to contribute with all the work that has been unlocked.
I don't mind doing this work, but I only have a 56K modem connection and
never have worked with CVS (could be this is time to learn), only have made
some checkouts.
Now, that we have find the problem (I'd better say the cause), I want to say
that I also commented out a section in the 2D init driver:
if (pATI-Chip = ATI_CHIP_264VT4)
{
outm(GUI_CNTL, pATIHW-gui_cntl);
pATI-nAvailableFIFOEntries = 0;
ATIMach64PollEngineStatus(pATI);
}
This code was updating the GUI_CNTL value, found to be zero for
Chip=ATI_CHIP_264VT4.
Anyway, why is this happening? Is it a card bug? In the register document the
00 value for this register is documented and valid (as the max FIFO length
value).
Well, talking about CVS. What do you think is better? I would made the update
in the CVS if you give me access. It could be nice if someone gives me a
little recipe to made the upgrade without problems, or at least, recommend
some guide about CVS.
--
M. Teira
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Slow MGA G400 and Return to castle Wolfenstein (and others)
Hi there, I'm strugling with my G400 performance for months now, since the 4.1 tree. Quake 3 is just not playable at some levels, Return to castle wolfenstein is not playable. Soldier of fortune is not playable anymore. I had contact with Jeff Hartman, and he told me that this was supposed to be a SMP issue. But i've tried the same config (RH7.1+Xfree4.1+G400 (PIII/BX chipset)) on a Uni-processor machine, and the same slowness as a result. I've heard from the avifile guys that there are some serious problems with the gcc version (2.96) supplied by RedHat in combination with MMX. Please can someone confirm this (with simalair config) Greetings Bas ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: BusMastering test seems to work
On Sat, 2001-10-20 at 11:18, Manuel Teira wrote: Well, talking about CVS. What do you think is better? I would made the update in the CVS if you give me access. It could be nice if someone gives me a little recipe to made the upgrade without problems, or at least, recommend some guide about CVS. http://dri.sourceforge.net/doc/cvspolicy.txt This helped me a lot to understand both how CVS branches work and how the DRI project uses them. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r128 and libXv
On Fri, 2001-10-19 at 14:52, M.G. Houtman wrote: Before Xfree 4.1.0, I always used the DRI CVS version for Xfree, 'cause it had the latest and (nearly always) the best drivers. Since 4.1.0 the standard sources contain the latest DRI sources, so I installed that version. Normally, DRI comes with libXv.a and libXv.so, thus a statically and a dynamic version. Not unless you explicitly #define SharedLibXv YES . Yet the latest 4.1.0 binraies come with only libXv.a. That's how XFree86 intends it to be. The pros and cons of this are currently being discussed on the Xpert list. During the xine configure, i do get a good message: checking for XvShmCreateImage in -lXv... yes checking for libXv.a location... found in /usr/X11R6/lib -lXv is the .so lib, correct me if I am wrong. How can it find it if it's not there? It will use the static library if it doesn't find a shared one. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Patch to initialize AGP registers
El Sáb 20 Oct 2001 18:02, Frank C. Earl escribió: We can work on parts of it. If you want to do the DMA part (and I won't stop you from it- having said this, I can do that part as well...), we ought to come up with some agreed upon code interfaces to it so that someone else can be plugging away with the Mesa end of things. I think it would be better that you started this task. I don't feel so optimist as yesterday, when the DMA started to work. ;-) I'm sure it'll be the best for the project. I have not the background needed for this and you will make it faster. BTW. It would be nice if the mach64 speed under DRI were 2 times than the speed got under Utah-GLX. It's not a Radeon, but it will be nice to play Q3 with this laptop. I will start the new branch in the CVS ASAP, when they give me access. Best regards ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
