RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity

Just for volunteers 

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@3192 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
nick 2001-11-28 18:49:40 +00:00
parent a882d43238
commit 040d3a77a3
1 changed files with 285 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

285
drivers/radeon/hacking Normal file
View File

@ -0,0 +1,285 @@
ATI chips hacking
=================
Dedicated to ATI's hackers.
Preface
~~~~~~~
This document will compare ATI chips only from point of DAC and video overlay.
There are lots of difference from 3D point, dual-head support, tv-out support
and many other things but it's already perfectly different story.
This document doesn't include information about ATI AIW (All In Wonder) chips.
What are units on modern ATI chips:
DAC - (Digital to Analog Convertor) controls CRTC, LCD, DFP monitor's output
Consists from:
PLL - (Programable line length) registers
CRTC - CRT controller
LCD/DFP scaler
surface control
DAC2 - controls CRTC, LCD, DFP monitor's output on second head
TVDAC - controls Composite Video and Super Video output ports
Consists from:
TV_PLL
TV scaler & sync unit
TV format convertor (PAL/NTSC)
TVCAP - controls Video-In port
MPP - Miscellaneous peripheral port. (includes ImpactTV(2+) - copy
protection mechanism)
OV - Video overlay (YUV BES) (include subpictures, gamma correction and
adaptive deinterlacing)
CAP0 - Video capturing
CAP1 - Video capturing (second unit)
RT - Rage theatre: video encoding and mixing
MUX - video muxer
MEM - PCI/AGP bus mastering
2D - GUI engine
3D - 3D-OpenGL engine (There are lots of stuff)
I2C - I2C Bus control
This document is mainly related only with OV unit ;)
Video decoding diagram:
RAM memory: [ App ] Copies YUV image to overlay memory
| <-- (It's possible to program DMA here)
overlay memory:[ OV ] performs scaling and YUVtoRGB convertion
/\
RGB memory: / \
/ [ ImpactTV ] performs copy protection filtering
/ \ (unneeded but presented by default thing;)
[ CRTC/LCD/DFP DAC ] [ TV DAC ] convert RGB memory to CRTC and NTSC/PAL signals
| |
[CRTC/LCD/DFP Monitor] [TV-screen]
History
~~~~~~~
What is history of ATI's chips? I can be wrong but below is my vision
of this question:
0. I don't know any earlied chips :(
1. Mach8
2. Mach16
3. Mach32
4. Mach64.
It's first chip which has support from side of open
source drivers. Set of mach64 chips is:
mach64GX (ATI888GX00)
mach64CX (ATI888CX00)
mach64CT (ATI264CT)
mach64ET (ATI264ET)
mach64VTA3 (ATI264VT)
mach64VTA4 (ATI264VT)
mach64VTB (ATI264VTB)
mach64VT4 (ATI264VT4)
5. 3D rage chips.
It seems that these chips have fully compatible by GPU with Mach64
which is extended by 3D possibilities. Set of 3D rage chips is:
3D RAGE (GT)
3D RAGE II+ (GTB)
3D RAGE IIC (PCI)
3D RAGE IIC (AGP)
3D RAGE LT
3D RAGE LT-G
3D RAGE PRO (BGA, AGP)
3D RAGE PRO (BGA, AGP, 1x only)
3D RAGE PRO (BGA, PCI)
3D RAGE PRO (PQFP, PCI)
3D RAGE PRO (PQFP, PCI, limited 3D)
3D RAGE (XL)
3D RAGE LT PRO (AGP)
3D RAGE LT PRO (PCI)
3D RAGE Mobility (PCI)
3D RAGE Mobility (AGP)
6. Rage128 chips.
These chips have perfectly new GPU which supports memory mapped IO
space for accelerating port access (It's main cause of incompatibility
with mach64). Set of Rage128 chips is:
Rage128 GL RE
Rage128 GL RF
Rage128 GL RG
Rage128 GL RH
Rage128 GL RI
Rage128 VR RK
Rage128 VR RL
Rage128 VR RM
Rage128 VR RN
Rage128 VR RO
Rage128 Mobility M3 LE
Rage128 Mobility M3 LF
7. Rage128Pro chips.
These chips are successors of Rage128 ones.
Rage128Pro GL PA
Rage128Pro GL PB
Rage128Pro GL PC
Rage128Pro GL PD
Rage128Pro GL PE
Rage128Pro GL PF
Rage128Pro VR PG
Rage128Pro VR PH
Rage128Pro VR PI
Rage128Pro VR PJ
Rage128Pro VR PK
Rage128Pro VR PL
Rage128Pro VR PM
Rage128Pro VR PN
Rage128Pro VR PO
Rage128Pro VR PP
Rage128Pro VR PQ
Rage128Pro VR PR
Rage128Pro VR TR
Rage128Pro VR PS
Rage128Pro VR PT
Rage128Pro VR PU
Rage128Pro VR PV
Rage128Pro VR PW
Rage128Pro VR PX
Rage128Pro Ultra U1
Rage128Pro Ultra U2
Rage128Pro Ultra U3
8. Radeon chips.
Indeed they could be named Rage256 Pro. (With minor changes is fully
compatible with Rage128 chips).
Radeon QD
Radeon QE
Radeon QF
Radeon QG
Radeon VE QY
Radeon VE QZ
Radeon M6 LY
Radeon M6 LZ
Radeon M7 LW
9. Radeon2 chips.
Indeed they could be named Rage512 Pro.
Radeon2 8500 QL
Radeon2 7500 QW
10. Radeon3 and newest are cooming soon, but I hope that they will be fully
compatible with Radeon1 chips.
In Radeon famility there were introduced also FX chips: Radeon FX and
Radeon2 8700 FX. Probably they have the same possibility as other Radeon
but currently it's unknown for me.
What about video overlay and DAC?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Currently it's known that there is only difference between
Mach64 and Rage128 compatible chips:
- They have different logic of io ports programming!
- They are incompatible by port numbers!
But:
- They use the same program logic from register's name point.
(Indeed exists slight difference even between Radeon and Rage128
chips. AFAIK only Radeon has OV0_SLICE_CNTL register which currently
is not used by driver. But I know only its name ;). Also there
is difference in slight adjust of BES position but it's configured
by #ifdef blocks).
Please compare:
(The piece of Back-End Scaler programming)
Sample for Mach64 compatible chips:
***********************************
#define SPARSE_IO_BASE 0x03fcu
#define SPARSE_IO_SELECT 0xfc00u
#define BLOCK_IO_BASE 0xff00u
#define BLOCK_IO_SELECT 0x00fcu
#define MM_IO_SELECT 0x03fcu
#define BLOCK_SELECT 0x0400u
#define DWORD_SELECT (BLOCK_SELECT | MM_IO_SELECT)
#define IO_BYTE_SELECT 0x0003u
#define SPARSE_IO_PORT (SPARSE_IO_BASE | IO_BYTE_SELECT)
#define BLOCK_IO_PORT (BLOCK_IO_BASE | IO_BYTE_SELECT)
#define IOPortTag(_SparseIOSelect, _BlockIOSelect) \
(SetBits(_SparseIOSelect, SPARSE_IO_SELECT) | \
SetBits(_BlockIOSelect, BLOCK_SELECT | MM_IO_SELECT))
#define SparseIOTag(_IOSelect) IOPortTag(_IOSelect, 0)
#define BlockIOTag(_IOSelect) IOPortTag(0, _IOSelect)
...
#define OVERLAY_Y_X_START BlockIOTag(0x100u)
#define OVERLAY_Y_X_END BlockIOTag(0x101u)
...
#define OUTREG(_Register, _Value) \
MMIO_OUT32(pATI->pBlock[GetBits(_Register, BLOCK_SELECT)], \
(_Register) & MM_IO_SELECT, _Value)
...
OUTREG(OVERLAY_Y_X_START,((drw_x)<<16)|(drw_y)|(1<<31));
OUTREG(OVERLAY_Y_X_END,((drw_x+drw_w)<<16)|(drw_y+drw_h));
Sample for Rage128 compatible chips:
************************************
#define OV0_Y_X_START 0x0400
#define OV0_Y_X_END 0x0404
...
#define INREG(addr) readl((rage_mmio_base)+addr)
#define OUTREG(addr,val) writel(val, (rage_mmio_base)+addr)
...
rage_mmio_base = ioremap_nocache(pci_resource_start (dev, 2),RAGE_REGSIZE);
...
#ifdef RADEON
#define X_ADJUST 8
#else /* rage128 */
#define X_ADJUST 0
#endif
OUTREG(OV0_Y_X_START,(drw_x+X_ADJUST)|(drw_y<<16));
OUTREG(OV0_Y_X_END,(drw_x+drw_w+X_ADJUST)|(drw_y+drw_h)<<16));
Thus - these chips have almost the same logic from register's name point.
(except the fact that they have swapped 16-bit halfs).
Yes - programming of Rage128 is much simpler of Mach64.
What about other ATI's chips?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I suggest you have latest copy of GATOS-CVS:
http://www.linuxvideo.org
GATOS was designed and introduced as General ATI TV and Overlay Sowfware.
You will be able to find out there a lots of useful hacking utilities
(at location gatos-ati/gatos):
gfxdump - Program for dumping graphics chips registers on Linux and Windows 9X.
(it's more useful for Win9x to hack their values).
xatitv - For working with tv-in (currently is under hard development)
atitvout- For working with tv-out
and lot of other stuff.
BUT: After studing of Gatos and X11 stuffs I've found that they are bad
optimized for movie playback.
Please compare:
radeon_vid - configures video overlay only once and provides DGA to it.
(doesn't require to be MMX optimized)
gatos and X11 - configures video overlay at every slice of frame, then
performs unoptimized copying of source stuff to video memory
often with using CopyMungedData (it's C-analog of YV12_to_YUY2)
since there are lacks in yv12 support.
(is not MMX optimized that's gladly accepted, but probably
will be never optimized due portability).
Conslusion:
~~~~~~~~~~~
That's all folk!