-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alex Deucher wrote:
> On 6/29/05, Hamish Marson <[EMAIL PROTECTED]> wrote:
>
> Alex Deucher wrote:
>
>> On 6/29/03, Rune Petersen <[EMAIL PROTECTED]> wrote:
>
>>> Hamish Marson wrote:
>
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> Hamish Marson wrote:
>>>>
>>>>
>>>>> Just as a status report...
>>>>>
>>>>> On my thinkpad r50p which has an rv350 (FireGL-T2) when
>>>>> using the current CVS xorg, CVS Mesa and the tagged r300
>>>>> driver 'the_perfect_frag') it all works, 1600fps on
>>>>> glxgears, but the flickering is awful on OpenGL apps...
>>>>>
>>>>> (Current CVS is yesterday for xorg, today for Mesa).
>>>>>
>>>>> glxgears - works OK. But flickers. tuxracer - works OK.
>>>>> Reasonable frame rates. But flickers at about 10Hz. gl-117
>>>>> - Same. Reasonable frame rates. But flickers.
>>>>>
>>>>> glxgears was in a window. tuxracer and gl-117 were
>>>>> full-screen. I had to stop before I threw up...
>>>>>
>>>>> Suspend & Resume worked OK so far (Only suspended to RAM
>>>>> once though).
>>>>>
>>>>> Hamish.
>>>>
>>>>
>>>> FWIW the same things also happens on the current CVS copy.
>>>>
>>>> This is with a 1600x1200 resolution LCD as well, just in case
>>>> it matters. gl-117 seems to geta round 60fps in the init
>>>> screens... But I can't see the screen well enough to navigate
>>>> through (Or access even) any setup screens to try & change
>>>> anything in it.
>>>>
>>>> H
>>>>
>>> Flickering should be resolved by adding this to radeon_driver.c
>>> in the Xorg: @@ -5631,6 +5627,11 @@ if (!info->IsSecondary)
>>> RADEONChangeSurfaces(pScrn);
>
>>> + if (info->ChipFamily >= CHIP_FAMILY_R300) { + unsigned char
>>> *RADEONMMIO = info->MMIO; + OUTREG(0x180, INREG(0x180) |
>>> 0x1100); + } + if(info->MergedFB) { /* need this here to fix up
>>> sarea values */ RADEONAdjustFrameMerged(scrnIndex,
>>> pScrn->frameX0, pScrn->frameY0, 0);
>
>
>>> Rune Petersen
>
>> According to the databooks, this is the correct behavior for high
>> res modes. What it does is bump the display0/1 priorities in the
>> memory controller. I'll be committing a slighly updated version
>> of this patch to cvs in the next few days.
>
> If anything, this patch made my display flicker even worse than
> without it. Frame rates seem slightly lower, but glxgears gets
> around 1450-1500fps at only about 50% CPU (vs 1500-1600fps and 100%
> CPU utilisation without the patch).
>
>
>> the flickering may be GL related. if you are using one head, try
>> this line instead: OUTREG(0x180, INREG(0x180) | 0x0100);
Nope.
Maybe it's not that..
With glxgears I get horizontal black bands across the window (Only the
glxgears window. The rest of the display is fine). These jitter around
up & down. (Actually looking very closely at the window, they MIGHT be
horizontal bands of a darker share of the gear colours. A bit hard to
tell if it's that or black bands at high speed... It's 1500fps after all).
With tuxracer, I get a pretty good background in the practice, with
the mountains in the background. Nice & steady. The mid ground (ice
patches & trees) also look good, but over this, all the foreground
stuff, like tux himself, the speedo etc are constantly overlaid by
horizontal blue areas of what looks like no drawing... I'm not sure of
the background gets the same treatment... it's hard to see, but it
looks like they just get horizontal bands of lightblue transparency or
opacity...
In the menus the background is light blue, the foreground is overlaid
with the flickering blue horizontal bands.
I was thinking sync issue maybe... (i.e. screen update not in sync
with the screen refresh rate of 60Hz).
>> that will only up the priority on display0.
>
> This is at 24bpp. Because @ 32bpp in xorg.conf, X doesn't start
> (Unsupported bit depth is the error).
>
>
>> depth 24 is 32bpp internally to the driver. there is no depth
>> 32.
>
That's what I thought.
> I also tried 1024x768 resolution. Same thing. (In fact tuxracer
> runs at a lower res I think. Hard to tell, I have the default
> screen expansion turned on for the LCD. Must turn it off).
>
> Alex. Are the databooks still a dire secret? Or can you share (If
> softcopy). Or can ordinary mortals get hold of them?
>
>
>> Sorry NDAs.
>
Ah well... I guess the world would fail if ATI let us all know how to
program their hardware. Good thing AMD & Intel don't think the same
about their CPU's...
(Sorry. Can't resist that).
H
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCwyJm/3QXwQQkZYwRAjg1AJ4uNxZpbxfDNFR1cqyiVDDFu2QOvwCfdnLi
zwX6is6Uc+pU9B+IvhJeDu8=
=li2R
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
