this register, but we're (still) waiting for quite some of
the docs to be released to the public we were given for radeonhd
development. There were supposed to be publicly available after some
time...
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409 Nuernberg
inconclusive.
I'd like to see Patch 1 applied. Patches 2 and 3 are just for reference.
If there is a different potential fix, I can reproduce the issue here
and would be able to test patches.
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409 Nuernberg
this updated patch work? If so, I'll apply it.
I'll test it now, but I assume so.
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ R D
On Dec 15, 09 10:57:37 -0500, Alex Deucher wrote:
Does this updated patch work? If so, I'll apply it.
Bingo. Runs fine.
Thanks
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de
Phone +49-911-74053-715
On Jul 06, 09 19:06:03 +0200, Sebastian Redl wrote:
Matthias Hopf wrote:
On Jul 03, 09 18:17:21 +0200, Sebastian Redl wrote:
But if anyone wants to go after the problem with the dynamic
configuration, I'm happy to help out.
Which xrandr version do you have? Note that xrandr doesn't
be that you're stumbling over the infamous uncloning bug. It's
fixed in xrandr 1.3.0.
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ R D
the graphics engine is just keeping up
with the refresh, slightly slower or slightly faster.
Could be a caching issue, pushing out the cache after each block might
help.
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409 Nuernberg
On Jan 13, 09 18:07:13 +0100, Xavier Bestel wrote:
On Tue, 2009-01-13 at 17:41 +0100, Matthias Hopf wrote:
tear free. Sometimes the diagonal tear can be seen in one or more (2..4
segments out of 11) of the 100 line segments. This last point is really
puzzling, this could indicate
a barrier, i.e. even if reordered
between them all writes before the flush should go.
Yes, but the beam could already in the middle of the screen if you flush
only at the end of all blocks.
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409 Nuernberg
. I don't have any better explanation, still.
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de
to a single clipped triangle; this means the triangle
If you're using guardband clipping, this means that you're really
rasterizing (and throwing away) an awful lot of pixels. And this is
still fast enough? Fascinating.
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409
on notebook chipsets (RS780 is the only
one, AFAIK) - but you would need to hack r600_demo.c a bit with the PCI
IDs at least.
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de
Phone +49-911-74053-715
--
Matthias Hopf [EMAIL PROTECTED] ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED]
Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de
___
xorg-driver-ati mailing list
xorg-driver
if
Current git of radeonhd should support dual link DVI as well, though
this is untested ATM.
CU
Matthias
--
Matthias Hopf [EMAIL PROTECTED] ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED]
Phone +49-911-74053-715
On Mar 17, 08 09:30:25 -0400, Alex Deucher wrote:
This is an issue with xine, not the driver. xine repeatedly forces
the monitor to unblank as a hack to keep the screen saver fro kicking
in.
Hm. Unblanking an already non-blanked monitor should be a no-op,
shouldn't it?
Matthias
--
Matthias
for that as
well. Maybe the AtomBIOS calls take more time than direct programming,
especially for DDC (e.g. you cannot ping with AtomBIOS), but that is
only a rough guess.
Matthias
--
Matthias Hopf [EMAIL PROTECTED] ____ __
Maxfeldstr. 5 / 90409 Nuernberg
to link them during
application runtime before downloading them to the graphics card.
CU
Matthias
--
Matthias Hopf [EMAIL PROTECTED] ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED]
Phone +49-911-74053-715 __) |_| __) |__ R D
understand the hardware, and program after that. You will end up with
pretty different code, I guess, if you do that. Also, we don't have
anything for the r6xx.
Unfortunately, you guys had to cope with not having docs at all, so you
didn't have that luxury...
Matthias
--
Matthias Hopf [EMAIL
On Oct 09, 07 18:38:59 +0200, Syren Baran wrote:
Am Dienstag, den 09.10.2007, 18:01 +0200 schrieb Matthias Hopf:
Unfortunately, you guys had to cope with not having docs at all, so you
didn't have that luxury...
I know this is off topic ..., but to much luxury tends to soften
people
.
The assembler is the most trivial aspect, and actually unnecessary. Mesa
already has a ARB_fragment_program and _shader assembler, and a OpenGL
2.1 GLSL compiler.
Matthias
--
Matthias Hopf [EMAIL PROTECTED] ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL
estimation.
CU
Matthias
--
Matthias Hopf [EMAIL PROTECTED] ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED]
Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de
___
xorg-driver
cannot comment on current negotiations.
Sorry, this is getting too political, I think I stretched as far as I
can go in public.
Matthias
--
Matthias Hopf [EMAIL PROTECTED] ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED]
Phone +49-911-74053-715
probably decided by the community.
My 2 cents
Matthias
--
Matthias Hopf [EMAIL PROTECTED] ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED]
Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de
23 matches
Mail list logo
