| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This will be handled with an option somehow.
|
|
|
|
From README.ati:
Clocks for supported programmable clock generators:
The driver currently supports all programmable clock generators known
to exist on Mach64 adapters.
Clocks for unsupported programmable clock generators:
This case is unlikely to occur, but is documented for the sake of
completeness.
Thus:
- check for (pATI->ProgrammableClock > ATI_CLOCK_FIXED) &&
(pATI->ProgrammableClock < ATI_CLOCK_MAX)
- drop "probe_clocks" option
- pATIHW->ClockUnmap is no longer used
- pATIHW->ClockMap is only used with NewHW.crtc which is always ATI_CRTC_MACH64
and has the identity map, so drop it
- (pATI->ProgrammableClock != ATI_CLOCK_INTERNAL) => (pATI->depth <= 8)
|
|
- cull (pATI->NewHW.crtc != ATI_CRTC_MACH64).
|
|
- (pATI->BankInfo.BankSize = 0) in all cases, cull pATI->BankInfo
- only keep the minimal pATIHW.SetBank interface for save/restore
- clean ATISwap() a little, (NewHW.crtc != ATI_CRTC_VGA)
- (UseSmallApertures == TRUE) <=> pATI->VGAAdapter
|
|
- cull (pATI->Adapter != ATI_ADAPTER_MACH64)
- treat pATI->VGAAdapter as Bool
|
|
- drop (pATI->OptionLinear == FALSE)
- AcceleratorVideoRAM is always set, i.e. VGAVideoRAM is not used
- pATI->LinearBase is always set
- xf86LinearVidMem() is now checked in atipreinit() for both CPIO and MMIO
atipreinit.c only:
- pVideo == NULL
- NewHW.crtc != ATI_CRTC_MACH64
This allows to drop the "no linear aperture" cruft.
|
|
- Chip < ATI_CHIP_88800GXC
- Chipset != ATI_CHIPSET_ATI
- Adapter != ATI_ADAPTER_MACH64
- depth < 8
|
|
- Chip < ATI_CHIP_88800GXC
- Chipset != ATI_CHIPSET_ATI
- Adapter != ATI_ADAPTER_MACH64
- depth < 8
atimode.c only:
- NewHW.crtc != ATI_CRTC_MACH64
This allows to drop VGACalculate(), VGAWonderCalculate() cruft early.
|
|
- ChipHasSUBSYS_CNTL
- Coprocessor
- SharedAccelerator
- SharedVGA <=> (VGAAdapter != ATI_ADAPTER_NONE)
|
|
This was not set anyway, because configure.ac would compute ATIMISC_NON_PCI and
then test ATI_AVOID_NON_PCI to set AVOID_NON_PCI...
|
|
This is mainly due to the cards having a different resource 1.
Fixes 6796
|
|
|
|
My 8500 in i845 doesn't work with fastwrites even setup by the firmware.
|
|
This might fix bug 9371
|
|
Since the reorganization of the mode setting code, the mode registers relying
on state already set (by bios) were not read, thus clearing out all bits the
driver does not touch. At the very least, this could lead to completely
nonfunctional to misbehaving dvi output (see bug 9495). Fix this by using the
SavedReg values, which also makes it more obvious that those are bits which
were not set by the driver previously, but come from register readback.
|
|
|
|
Also round up to the maximum width and height, as that's what EXA compares.
|
|
Based on the assumption that firmware should have set up the card and host
bridge appropriately for these settings, this may actually be safer, at least
for the transfer rate; leaving fast writes enabled is hopefully safe as well,
it certainly is on my sytem.
See https://bugs.freedesktop.org/show_bug.cgi?id=9284 .
|
|
This reverts commit 48ff33a1770f3684cd50184db8f1944a456d9974.
|
|
|
|
It is not necessary to always emit a OUTPLL/INPLL pair when we display
a video frame. On some chips there are erratas for which the workarounds
cause a 10ms delay by those calls. This is related to #5876 though those
affected may suffer from other slowness issues too.
|
|
This unclutters RADEONPreInit() somewhat, but more importantly moves comparison
against info->ChipFamily after that's initialized.
|
|
Instead of calling the DRM CP idle ioctl, just emit the cache flush commands
into the CP stream.
|
|
|
|
fix the forgotten leftuv value for packed yuv which is
needed to get correct uv starting pixel (fixes broken clipping /
non-null src start pixel as tvtime uses)
|
|
Radeons can do planar yuv just fine, there is no need to convert all data
to packed yuv manually. This saves some cpu cycles as well as some
(graphic card) ram.
|
|
|
|
|
|
|
|
Still not allowing any clone modes, but heading in the correct direction
I hope... there is a chance this will regress something from superpatch..
|
|
|
|
This is leading towards randr-1.2 believe me :-)
|
|
|
|
|
|
Works with 1920x1080 video on my M10.
|
|
|
|
Use the overlay scaler's predownscale capability to make videos with large
horizontal resolution work if it exceeds the scaler buffer width. Make the
scaler buffer width user-configurable since we don't know it for all chips,
and using predownscaling may otherwise reduce quality even if it wouldn't
be needed. This should fix bug #1462.
|
|
|
|
In theory the driver should be able to handle the front buffer not at VRAM 0
In practice it didn't.. this is cleanup for at least XAA parts of the driver
to allow for the frontbuffer to move. It has to re-organise a large part of ScreenInit so things happen in the correct order otherwise some things get setup in-correctly. (not sure EXA with fb not at 0 works yet...)
|
|
|
|
problems on asus laptops (see bug 7463). We don't support video-in
on any laptops at the moment anyway.
|
|
patch and testing from Alain Péteut
|
|
We still have to force-sync the pages on enabling page flipping with XAA as the
second page may have been clobbered by the offscreen pixmap cache since they
were last synced.
|
|
|
|
|
|
|
