Am 23.07.2013 00:42, schrieb Grigori Goronzy:
On 23.07.2013 00:30, Dave Airlie wrote:
On Mon, Jul 22, 2013 at 2:06 PM, Grigori Goronzy g...@chown.ath.cx
wrote:
Subpixel text rendering is typically done with a solid src and a
pixmap mask. Traditionally, this cannot be accelerated in a single
Am 14.06.2012 21:19, schrieb Dave Airlie:
I'm seriously thinking of resurrecting the kms killing branch, can
anyone give me a reason not too,
we'd fork the current master into a UMS branch and move on.
Aren't there still some OS using this driver but not supporting kms?
Though I guess it
Hi,
I thought those gr_gb and rg_bg formats were a perfect match for packed
yuv data. That should make the code simpler and faster (though unless
you've got some HD3000-class IGPs that shouldn't matter at all).
There's only a slight problem, it doesn't actually work...
The colors are just all
Ok I found it sending new patches tomorrow...
Roland
Am 11.05.2012 04:01, schrieb Roland Scheidegger:
Hi,
I thought those gr_gb and rg_bg formats were a perfect match for packed
yuv data. That should make the code simpler and faster (though unless
you've got some HD3000-class IGPs
Those formats were invented for exactly that purpose so use them.
This saves some code and also some hw resources (only need one
sampler instead of two for packed yuv).
(Note the output is not quite pixel exact probably some rounding errors
on coords before caused some subtle chroma filter bugs,
make sure the division is done with floats, otherwise the coordinate
can be wrong up to 1 texel.
Particularly visible with clipping and small source scaled up (since one
texel can be a shift of several pixels) but could be seen even unscaled.
Should provide more accurate coords without clipping
make sure the division is done with floats, otherwise the coordinate
can be wrong up to 1 texel.
Particularly visible with clipping and small source scaled up (since one
texel can be a shift of several pixels) but could be seen even unscaled.
Should provide more accurate coords without clipping
Hi,
I think that the textured video code doesn't quite handle the chroma
values right. It uses the same texture coords for luminance and
chrominance values. mpeg2 however actually defines the chroma samples to
be vertically between two lines (for non-interlaced content anyway, I
won't go into the
IIRC this is not only true for r200. Might be true for r300 too, and
r100 (possibly not rv100) even. Looks good otherwise though.
Roland
Am 05.12.2011 19:46, schrieb Dave Airlie:
From: Dave Airlie airl...@redhat.com
When we do the allocations we need to make sure the always tiled
nature is
Am 05.12.2011 21:51, schrieb Dave Airlie:
On Mon, Dec 5, 2011 at 8:08 PM, Roland Scheidegger
rscheidegger_li...@hispeed.ch wrote:
IIRC this is not only true for r200. Might be true for r300 too, and
r100 (possibly not rv100) even. Looks good otherwise though.
Yeah I've been trying to solve
On 10.02.2010 15:12, Pauli Nieminen wrote:
Hi!
I made some testing how fast my system can move data to VRAM/GTT and I
got very interestig results:
(II) RADEON(0): BENCH: copy 3129344 bytes to vram took 78595us,
resulting in 39Mbps
Mbps is a bit confusing I can only read that as Megabit
On 14.12.2009 15:22, Alex Deucher wrote:
XAA render support seems to be broken (fdo bug 22055, possibly
others). It never really did much to begin with, and it only
supported r1xx and r2xx. Any objections to me dumping XAA render
accel in the radeon driver?
Hmm, personally I was never able
On 14.12.2009 20:33, Alex Deucher wrote:
On Mon, Dec 14, 2009 at 2:21 PM, Roland Scheidegger
srol...@tungstengraphics.com wrote:
On 14.12.2009 15:22, Alex Deucher wrote:
XAA render support seems to be broken (fdo bug 22055, possibly
others). It never really did much to begin
On 25.09.2009 07:22, Dan Engholm wrote:
Dear list,
I have a PC with an ATI FireGL V3400 display adapter. It has two flat
panel LCD monitors connected via DVI and I want to set it up with a
single desktop spanning the two. After some research, I figured that I
had to install the ATI
On 01.09.2009 12:52, James Cloos wrote:
Alex What's the problem with textured video? It should perform as well
Alex or better than the overlay without all the limitations.
It is not a question of performace but of features.
The overlay supports 8 formats and 22 attributes (more on hw
On 31.08.2009 07:13, James Cloos wrote:
The XVideo corruption also occurs w/o KMS if I specify the textured
video rather than the overlay. It is not a KMS thing.
OTOH, given that textured video on r100 is pretty pathetic, the real fix
would be to add overlay video support to KMS.
Not sure
On 28.08.2009 00:08, James Cloos wrote:
On the XV front, I did find 7131 instances of:
CS section size missmatch start at
(radeon_textured_videofuncs.c,RADEONDisplayTexturedVideoCP,221) 46 vs
52 CS section end at
(radeon_textured_videofuncs.c,RADEONDisplayTexturedVideoCP,307)
in the
On 10.07.2009 00:06, wild-thing wrote:
Hello there!
I guess this could be a feature request: (An unusual question)
I am sure you know BOINC: http://boinc.berkeley.edu/ I am spending
processor time for one of the related projects as user only. And
there is possibility to use a
On 19.01.2009 20:21, Christiaan van Dijk wrote:
Hi all,
here's a summary of the experiments I have been doing.
* A RS690 can not render a full-HD image in the vertical blanking time
(@50Hz) but the engine should easily be able to render a full screen
when split in two halves. This is the
On 29.07.2008 20:43, Thomas Hilber wrote:
On Tue, Jul 29, 2008 at 02:23:09PM +0200, Roland Scheidegger wrote:
That's true but last I heard CRT TVs are a dying breed.
who cares:)
Ok, I see your point. But if your output device is a projector, LCD (not
sure about plasma right now) at some
On 30.07.2008 21:17, Thomas Hilber wrote:
On Wed, Jul 30, 2008 at 04:17:10PM +0200, Roland Scheidegger wrote:
Actually, this is a very interesting patch. I've been thinking
about this a bit lately. How much jerkyness do you actually get
when it's not synchronized? I'd assume that if you use
On 29.07.2008 13:25, Thomas Hilber wrote:
On Tue, Jul 29, 2008 at 08:11:21AM +0200, Michel Dänzer wrote:
On Tue, 2008-07-29 at 01:43 +0200, Roland Scheidegger wrote:
high quality and RGB/PAL doesn't really fit in the same sentence if
you ask me...
Probably nothing beats a good TV when
On 28.07.2008 15:12, Corbin Simpson wrote:
Michel Dänzer wrote:
On Mon, 2008-07-28 at 13:06 +0200, Thomas Hilber wrote:
I assume this is due to scheduling latency between the vblank interrupt
and the textured video rendering getting emitted from userspace. It may
be possible to avoid this by
On 25.07.2008 20:09, Thomas Hilber wrote:
But it appears that even if I supply the following parameters to
RADEONPutImage():
src_x 0 src_y 0 drw_x 0 drw_y 0 src_w 720 src_h 576 drw_w 720 drw_h 576
the source is not copied exactly 100% to the destination. It appears if
there still takes
On 29.07.2008 00:15, Svilen wrote:
Hi,
I was wondering whether your driver supports accumulation buffers and if
yes how to enable them.
Here is my platform:
X1600 Mobility Radeon
Linux, Fedora 9
Xorg 7.4 (unofficial)
Mesa 7.1 (unofficial)
xorg.conf
...
Section Device
On 28.07.2008 17:56, Thomas Hilber wrote:
(Though, IMHO interlace should have been buried along with analog
transmission - this clever 1930-ish hack just doesn't make much sense
any longer and is just cause for pain...)
interlace output still is important for driving conventional TV
On 28.07.2008 22:43, Thomas Hilber wrote:
wow! it's unbelievable!
I couldn't sleep and finally restarted to test a few things.
On Mon, Jul 28, 2008 at 03:43:45PM +0200, Roland Scheidegger wrote:
you look at the displayvideo part, this one uses some of these bits).
Also, to disable
On 02.07.2008 19:25, [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] [08-07-02 18:56]:
On Wed, Jul 2, 2008 at 12:17 PM, [EMAIL PROTECTED] wrote:
Hi,
When using Blender my radeon_dri driver crashes with a segfault (and
Blender follows :-/ ). But it only happens when some very
Michel Dänzer wrote:
On Wed, 2008-04-30 at 14:39 -0400, Alex Deucher wrote:
On Wed, Apr 30, 2008 at 3:06 AM, Michel Dänzer
[EMAIL PROTECTED] wrote:
On Tue, 2008-04-29 at 16:52 -0400, Alex Deucher wrote:
On Tue, Apr 29, 2008 at 4:34 PM, Alex Rades [EMAIL PROTECTED] wrote:
Hi,
when
Alex Deucher wrote:
On Thu, May 1, 2008 at 6:49 PM, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Michel Dänzer wrote:
On Wed, 2008-04-30 at 14:39 -0400, Alex Deucher wrote:
On Wed, Apr 30, 2008 at 3:06 AM, Michel Dänzer
[EMAIL PROTECTED] wrote:
On Tue, 2008-04-29 at 16:52 -0400, Alex
Don't the the WAIT_UNTIL_CRTC_VLINE, WAIT_UNTIL_FE_CRTC_VLINE,
WAIT_UNTIL_RE_CRTC_VLINE conditions only work correctly when the
CRTC_GUI_TRIG_VLINE register is configured appropriately?
Roland
Alex Rades wrote:
I've also just noticed that the above behaviour only applies when
running
Bajji sw wrote:
Thanks for the response.
Maybe the act of giving up and asking for help opens
one's eyes to the solution? I have noticed this a few
times recently :) .
I tried enabling radeon on another machine (9600 Pro,
not AIW) and discovered that AGPFastWrite is the cause
of the
Bajji sw wrote:
Hi there,
Can I use X.org Radeon drivers to make a 128MB AIW
Radeon 9700 Pro work with a DCI LCD without fglrx ?
Why you ask? With fglrx and DRI enabled, even SD video
is choppy. Processor is AMD Athlon XP ~3000.
fglrx on a ATI Rage mobility 8MB makes SD video
smooth.
Michel Dänzer wrote:
On Sun, 2007-11-25 at 14:42 -0800, [EMAIL PROTECTED]
wrote:
http://bugs.freedesktop.org/show_bug.cgi?id=12934
--- Comment #8 from [EMAIL PROTECTED] 2007-11-25 14:49 PST ---
(In reply to comment #7)
Does Option AGPMode 1...
No, unlike AGPMode 2, 1 does not
Dirk Meier wrote:
Am Freitag 19 Oktober 2007 schrieb Dave Airlie:
Wierd you have direct rendering.. I'm not sure why you don't get
glxgears working..
It looks like SuSE have some wierd patches to Mesa for updated
drivers
the lack of drirc shouldn't matter..
so does LIBGL_DEBUG=verbose
35 matches
Mail list logo
