El Sáb 15 Sep 2001 18:02, escribiste:
> Sorry, haven't had much time to package things up (I barely had time to do
> what little I tried this week to get the hang, with all the insanity going
> on)- I'll try tomorrow or monday to get it all back out.
>
OK, I know you are busy. I'm expecting your changes to learn about them.
> And, yes, I do think so and I was about to do the same...
>
> Digging through the code for the X driver, I find strange things that do
> not match up with what the documentation ATI has handed us (and the draw
> test code I have proves the documentation at least partly correct...). I
> find it setting bits that have no documentation for them (grey bars in the
> bit field descriptions mean that they're un-used/reserved). I find it
> setting bits that are documented, but have completely different meanings
> than what the code's comments indicate.
Could you put me an example. I have not an exact idea of how the
initialization process is fired by the 2D driver. Perhaps you're talking
about the mach64preinit.c?
It would be nice if you could post me a list of the different suspicious
register writes to contrast them with the docs I have.
>I find it keeping the engine's
> entire state when all it needs do is query it directly (Which is a
> potential for other problems- what if those duplicated state variables are
> out of sync for any reason?). In short, it almost looks like the driver is
> a mess. Right now I'm trying to sift through it and the old 3.3.6 server
> code to see what I can do to straighten this out in the short term and what
> I'd need to do to make it more robust in the long term. We're not likely
> to get bus-mastering going with it in the state it's in.
Perhaps the DRI Mach64 driver depends a lot on the 2D driver initialization.
On the other hand, the 2D driver is really difficult to follow because it's
made for a lot of different ATI Cards (actually for all the models from the
VGAWONDER and Mach8 accelerators to the Mach64).
BTW. Could anybody say me what is the AVOID_CPIO define used for ?
>
> By the way, gang, Gareth's old code has hacks in it to allow you to run
> accelerated 3D within Mesa so long as the DRI driver isn't loaded- gets
> about 115-120 fps in gears on my PII 450 with the code I have in hand from
> Manuel (His first pass at this...). I do agree with his sentiment that it
> has no business being in the trunk, but I do believe with the new
> re-worked, repackaged stuff, we have the makings of a new branch for the
> CVS tree.
Do you think we need to startup from another code base? I made the Gareth's
code migration to the XFree4.1.0 CVS trunk, but somebody said before that
there's a newer trunk for the DRI.
My opinion is that we need urgently to have a common codebase for all the
people interested to work in the Mach64 driver. So, if you think we must
merge with the DRI newest trunk please make me know.
> Indeed. But the only way to get people demanding it and the companies
> thinking it is worthwhile is for us to do the DRI work (or something else
> like it...) so that they know there is a demand. The Linux buying public
> doesn't do the brick and mortars- so the stores don't know what the demand
> is, or worse, don't think there's a potential market. The Linux buying
> public won't be buying cards without drivers for their card, open or closed
> source- so they don't know that there is a potential demand for their
> cards.
Well, I'm just a newbie here. I don't consider myself a graphic programmer,
and posibly I'll never be. I'm a programmer in the 'real world' but in a very
higher level approach. My only aim is to learn and to see my laptop 3D
working. So, I don't mind working in an obsolete hardware support. Anyway I
understand that high level developers here like to work with the newest
designs.
Best regards.
--
M. Teira
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
