Re: [Dri-devel] Mach64 work

[<AKa...@t-...>]

Hello!

It's late here in Germany and I must get up early next morning, so I
only want to post a few notes.

Frank Earl wrote:
> The following are observations, based off of things on my system:
> 
> If you don't do the DMA test at init time, it doesn't lock.  If you do
> anything with the accelerator (at least on my machine!) in the DMA init code,
> it hangs 2D in varying ways from a black screen to partial renderings of the
> login screen, etc. before locking up.  If you do the test just before shut
> down, it does nothing.  If you attempt to use the draw engine it's fine.

This happended to me after my merge. With the stuff I downloaded from
the branch I got this drm_idle thing but the server ran with the 2D
failures, gears locking the system and when trying to switch to text
console the screen got messed up and no input wasn't possible. After
getting the docs I rewrote the reset_engine function like described
there. Gareth switched to mach64 commands and left out something (I
don't know if this was his intention ;-)
After this I got the still the idle error but I inserted an engine_reset
for this case after the wait_for_idle call. So, the server has had
(believing glxinfo) DRI with hardware acceleration enabled. But gears
locked still the system. Apart of one time! I couldn't reconstruct this
case. Perhaps a lucky right setting. Then gears schowed a performance
increase of nearly 400 percent but the buffer swapping didn't worked
correctly. Instead of the gears I got textures from TuxKart wich I've
tested before (also with texture errors).
Since the failures in 2D graphic also arises when no drm module is
loaded I decided to merge to an stable version, but as mentionened this
broke thing completely so that I had to restore my distros server.    

> I don't know how much you can do without the info.  Could you tell if it's
> code in the abstraction layer or in higher levels of the server system?
> Without something to look at, you'd never know.  From my observations of
> stuff on at least my machine, it appeared that the Primary register aperture
> was turned off- without it being on, there IS no DMA.  If my observations
> were correct, nobody would ever have known that this was the case- without
> first having the register info and programmer's guide.

At least on my system there are problems wich are not directly related
to mach register programming. For example XAA: without drm module loaded
I get a lot of slots (128, 256, 512) but with the module only 8 128x128 
I haven't examined if this is really a problem but this example should
only show that there are other things, too.
An other goal should be (for people with docs to help others without
them) to make the programming of the mach64 more consistent. That means
that in to parts of the code are used different MACRO-names and #defines
for the same purpose: in drivers/ati and in the drm/kernel. If this is
consistend one should think of encapsulating frequent used techniques
(such as GUI master). So work could be dispatched: people with docs
write the encapsulated code and others use the defined interface in
higher level programming. This issues is a bit more for the future. But
this could also help regarding ATI like "Hey look! Software fallback
works, but hardware doesn't though it's implemented as discribed in the
docs." Perhaps there would be somebody interrested in that topic on ATI
side.
But this is only possible if and only if a working code base is
established to exclude other sources of failure.
Therefore I'll aply Manuel's patches tomorrow night.

@Manuel: Please send me your patches via mail, thanks.
   
It is time now to sleep, good night
Andreas Karrenbauer