On Wednesday 22 August 2001 13:45, Andreas Karrenbauer wrote:
> Hello all!
Welcome back, Andreas!
> BTW in meantime I officially received technical docs from ATI but under
> the same restrictions like all other ;-(
Stinks, doesn't it? Interesting that you've gotten them, though- other
people have had little to no luck getting them. Anyhow, it's one more person
with all the pieces in hand to help out...
> sure, they contain lots of interresting information, BUT I think that
> there's enough work to do wich doesn't need the docs at all. Furthermore
> a main part is excluded: 3D! (as mentioned before)
I think that Gareth kludged in something that did direct register writes- at
least it's what it looks like. DMA's not there except for the init test-
which is where Gareth stopped, I think.
> That is the first thing I suggest to do. My mach64-branch is in really
> bad shape (2D graphic errors an so on). Therefore I decided to merge the
> DRI parts to the (for me stable) sources of my distro. But that broke
> things and because of other work wich needs kde I stopped.
I think his patches work pretty well. I've had minimal disruptions with my
environment at this point- well other than the hard-hangs I've gotten trying
DMA operation on my box...
Manuel, I'd like an update, by the way- you've done quite a few things, I'll
bet. I'd also promised an update from me, well, I'd like to catch up with
your latest, modify it to what I've done and hand that back to you...
Basically, I discarded my old attempt and started over with your base code
changes. From there, I took the code doing the DMA test, cleaned it up with
macro definitions and split it off from the DMA init code. I also borrowed
draw test code from the Utah-GLX tree and made it direct rendering to see if
I had mappings, etc. right. This is where I am at this point with my
> I think it is very usefull if all interrested developers have a least
> common denominator where at least the 2D stuff is working and the
> machine doesn't lock at initialisation.
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.
> Another point is PLANNING and DISPATCHING work. In the past there were a
> few people playing around with the code and a few conversation. But no
> code or patches were exchanged. There are several people with the docs
> so they could concentrate on things wich need special insight in the
> specs. But there are other things to do as well (not so popular and
> maybe dirty work but wich is needed as well).
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.
> Gareth could you please point out where in the drivers code the GUI
> mastering is needed expect in dma_init. I grepped the source code for
> GUI_TABLE register manipulation but I found only in the init routine.
> Whats its purpose there (in an working envoirnment) apart from testing
I couldn't find any either- he's probably done what I'd have done, checked to
see if he could get GUI mastering working at the init point. Apparently
that's where he'd gotten stopped dead cold on things.
> If it isn't used elsewhere in a substantial way we could temporarily use
> the software fallback idea from Utah code. So this problem degenerates
> to a performance issue.
I think we could work towards that- however, that's going to require one of
us (namely Gareth, yourself, or myself) to find some way to stitch that in (I
agree, we probably ought to have some fallback operating modes lurking in
there somewhere...). I'll look at what I've got from Manuel at this point
and see if there's a quick and dirty way to make that happen- so we can
officially re-start the branch.