Re: [Dri-devel] MGA patches

[Jeffrey I. <jhi...@ix...>]

I just gave these patches a whirl with XFree86 4.1.0.  This has
definitely fixed two *major* nagging issues I had with several programs,
most notably Blender and the EVAS demos.  Previously, moving or shading
the windows in Sawfish would cause the X server to lock up, and I had to
login remotely and kill/restart X.  This has most *definitely* fixed at
least these two problems.

Jeffrey H. Ingber (jhingber _at_ ix.netcom.com)


On 08 Aug 2001 01:54:24 +0200, Ralf Hoffmann wrote:
> Hi,
> 
> I took the last two week to found the problem I have with my G450.
> This are my comments:
> 
> I (and also some others) noticed some graphic-problems and lockups.
> The graphic-problems are hard to descripe but I have made some shots from
> UnrealTournament (ver. 436) at http://www.boomerangsworld.de/ut-pics/
> Especially the picture http://www.boomerangsworld.de/ut-pics/ut1-wrong1.jpg
> (around 70kb) shows the problems. All this pics were taken with disabled
> multi-texturing!
> All problems appears only for one frame a time.
> 
> The problem (please correct me if I misunderstand something):
> The card is programmed via DMA and some commands contains a secondary dma
> address. This address belong to one of the 128 buffers and contains f.i.
> coordinates. The card read the commands via (so called) primary dma from the
> value of register PRIMADDRESS to PRIMEND.
> I think the problem is the aging of these buffers. The current code reuse a
> buffer when PRIMADDRESS is greater then position of the command which using the
> buffer.
> But what it really means is that only the commands are transfered to a
> on-card-buffer but they are possibly not executed yet.
> Because there are 128 buffers this is normally unlikely but it only happens for
> one frame for seconds.
> But in this situation the buffer get reused before it's transfered via
> secondary dma to the card. This means the card get wrong values resulting in
> best case only some graphic problems but in worst case an engine lock.
> 
> What's the solution?
> 
> The best solution would be to check if the buffer the code want to reuse is
> already processed. Perhaps there is a hardware-register for this but I don't
> have the docs so it's not possible for me.
> 
> I choosed this solution:
> All buffer sended to the card are marked as in_used and will not be used until
> all buffers are used once.
> Then all dma-commands are flushed and the code waits until the engine is idle.
> Then all buffers are marked as free and they get used again once.
> 
> I know it's not the best solution but there is no noticeable slow down
> (glxgears, isosurf and unreal shows the same fps then before).
> 
> On the other hand this solves any of problems including graphic-problems and
> lockups in Unreal, DoomLegacy, Heretic2 and Soldier of Fortune.
> 
> All this results in three patches I attached but also put at
> http://www.boomerangsworld.de/dri
> 
> The first patch contains only some bug-fixes for the original code. This bugs
> mainly only appears when all of the 128 buffers are given away which normally
> not happen. To the developer: Please double check this, especially the
> dev_prim->prim.end calculation!
> 
> The second (and important) patch contains the solution I descriped above and
> applies on top of the first one.
> 
> The third (independent) patch only adds the check for env-variable
> MGA_DISABLE_MULTITEXTURE and disable the multi-texturing extension in this case.
> This is because some apps are really slow with multi-texturing (f.i. Heretic2
> is a little bit slower, Soldier of Fortune isn't playable with mutli-texturing
> (<5 fps in some situations on my PIII 800) but Unreal is faster with
> multi-texturing).
> 
> The first two patches are kernel-module-changes so don't forget to compile and
> insmod the module!
> 
> Give it a try and comments are welcome!
> 
> Ralf Hoffmann
>