> >
> > 2. *_video.c files - these are heavily modified. Take care of atixv.c -
> > Marc Aurele merged part of GATOS code into XFree86
>
> Yes, I noticed that... these files were *FULL* of conflicts against the
> current DRI CVS... to the extent that I'm worried about being able to
> untangle them. Something like 140K of .rej files between radeon_video.c
> and atixv.c. It would help to know from the DRI folks, if they've done
> any major structural changes or if this is just bugfixes and minor code
> movement.
for radeon_video.c and r128_video.c this should be easy. The rejects are
likely caused not by modified code but by modified surroundings, so that
patch does not know where to insert new code.
They way I work through these is to open new radeon_video.c,
radeon_video.c from current gatos code and rejects and work one by one
to resolve the conflicts.
For example, the functions that initialized and access i2c bus can be
copied as is, whatever the modifications in surrounding code.
On the other hand the function that creates PortPrivPtr struct is best
changed so that attribute allocation (xv????? variables) happens anew
on each reset of the Xserver.
> > move apertures (from chips point of view) so as to allow for PCI DMA.
> >
> > These are matched by changes in drm-kernel and Mesa driver. They
> > are just a few lines.
> >
> > All of these are best thrown out and instead new code should make use
> > of ability of DRI CVS to change these settings dynamically.
>
> OK, can someone give me an idea of what calls I'm looking for, and what
> they should be doing instead? Are we talking strictly about what's in
> {radeon,r128}_dri.c?
>
> >From what I understand the changes in this area are the main cause of my
> problems. I can isolate what Gatos changed in this file, sure, but I
> have no idea what to replace it with.
There are two areas in xf86 driver: radeon_*dri.c and (AFAIK)
radeon_accel.c or similar.
Only radeon has such code, r128 does not have memory controller like
radeon does.
There are two areas: code that checks for compatible DRM. You don't need
it.
Code that handles trasferred apertures - this code looks like it adds a
constant value (aperture location in PCI address space) to some values,
but not others.
You need to ask DRM driver to transfer aperture to the same position
(so that video ram is at physical PCI adddress from the point of view of
radeon memory controller and AGP memory is right after it) and add
constants in the exact same places.
However, take note that since DRM driver in DRI CVS is aware of the
transferred apertures some of the additions would not be necessary as they
are done by the driver anyway.
As I remember that additions classify as following:
1. Some registers are simply set to physical PCI aperture, instead of 0
as they are now. For example, RADEON_OVERLAY_BASE_ADDR and
RADEON_DISPLAY_BASE_ADDR
2. Some registers have a constant value added, for example
RADEON_MC_AGP_LOCATION
3. You need to add a value to some, but not all values that refer to
data used by graphics engine.
The reason is that some values are offsets with respect to *BASE_ADDR
registers and some are not.
1. Texture locations are absolute - this allows (in principle)
to load texture from any of video ram, agp space or using PCI DMA
2. Vertex lists are absolute
3. There is a copy command that takes absolute arguments
so you can use it transfer data between video ram, AGP and PCI
spaces.
As a rule, an absolute register needs to be 32 bit - it cannot be 20
bit for example, as the apertures are often located at high addresses.
So if you see a register that is only 20bit wide there is no reason to
adjust it.
When I was modifying the driver I was able to progress along the
following milestones:
1. Move the aperture locations and get regular 2d operations
working without DRM driver (disable it or something)
2. Get overlay working - usually involves setting
RADEON_OVERLAY_BASE_ADDR correctly.
3. Enable DRM driver and get 2d operations working.
4. Get glxgears working - this means vertex lists work.
5. Get Quake working - this means texture now work.
6. At this point I believed that everything works, so I released
the code.
7. Receive bug reports (especially about Blender, Wolf3d and
some other apps).
8. After much digging it turns out that Mesa3d driver like to
do memcpy from one place of video RAM to another for
buffer swap or similar. This needs to be modified - but this
might already be implemented in DRI CVS.
>
> > 5. They are might be a few fixes (1 or 2) that are, strictly speaking,
> > outside the scope of GATOS code (like DPMS and such) and were
> > backported from XFree86 CVS tree. If they are indeed there they should
> > be easy to spot.
>
> I'm guessing the changes to atiprobe.c fall into this category
> atiregs.h seems to mostly be this sort of change, I'll have to pick
> through by hand to be sure... also there seem to have been a few
> endianness fixes merged in.
>
atiprobe ? Ignore them. These are just new PCI ids and DRI CVS should
already have all of them.
best
Vladimir Dergachev
>
> Thanks for responding,
> - Hod McWuff
>
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
