On Tue, 01 Mar 2005 17:02:07 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> Hrm... I tend to disagree :) MergedFB is a hack imho. It's much saner in
> the long run to fix the issues of multi-card Xinerama.
I haven't played with merge-fb so I may not understand it right, but
doesn't it
On Tue, 2005-03-01 at 17:02 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2005-02-28 at 15:09 -0500, Michel DÃnzer wrote:
> > On Mon, 2005-02-28 at 10:19 -0500, Alex Deucher wrote:
> > >
> > > I think long term though, a better solution would be to get rid of
> > > mergedfb and handle each head s
On Mon, 2005-02-28 at 15:09 -0500, Michel Dänzer wrote:
> On Mon, 2005-02-28 at 10:19 -0500, Alex Deucher wrote:
> >
> > I think long term though, a better solution would be to get rid of
> > mergedfb and handle each head separately but just change the 2d/3d
> > engines offsets depending on which
Zoltan Boszormenyi wrote:
Hi,
I am running the Linuxconsole.sf.net multiconsole extension on my
machine and I have a Radeon 9200SE/AGP8x and a PCI Radeon7000VE. Both
cards are driven hardware accelerated with DRI.
I noticed behaviour differences running Tuxracer/PPracer between the
two cards.
T
Dave Airlie wrote:
2. make ycbcr on r200 dependant on a new chipset flag.. if your chip has a
broken ycbcr (r200 and rv280 look fine so far..) then the flag needs to be
set for it...
I removed support for ycbcr some time ago on everything except r200
based on the assumption that it was just a feat
On Mon, 2005-02-28 at 10:19 -0500, Alex Deucher wrote:
>
> I think long term though, a better solution would be to get rid of
> mergedfb and handle each head separately but just change the 2d/3d
> engines offsets depending on which head you are rendering to. then
> you wouldn't have to worry abou
Vladimir Dergachev wrote:
fglrx will do on r300. I'm wondering about that though a bit, that
would be 11.3 bit for coords or so ;-). It would also mean the tiling
regs need to be different a bit on r300 compared to r100/r200.
I looked through the register manual for Radeons and it looks like th
Roland Scheidegger wrote:
Wasn't the limit 2560x2560 with the r300 based chips? That's at least
what fglrx will do on r300.
The limit seems to be 2560 on r300 (high end) cards, but 2048 on rv300
cards (these cards really look like they have exactly the same tiling
regs as r200).
Stephane
---
* need to check that we have enough of zbuffer/doublebuffer allocated
to accomodate this..
What does everyone think ?
Wasn't the limit 2560x2560 with the r300 based chips? That's at least what
Maybe, I have not measured it. I only know it is less than 3000+ pixels
that merged fb uses on my set
On Mon, 28 Feb 2005 19:46:07 +0100, Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
> Vladimir Dergachev wrote:
> >>>
> >>> By default r300_demo and r300_driver have tiling enabled at 16x16 pixel
> >>> squares, in fact the card should come up with this on by default..
> >>>
> >>> Now on to the next q
Vladimir Dergachev wrote:
By default r300_demo and r300_driver have tiling enabled at 16x16 pixel
squares, in fact the card should come up with this on by default..
Now on to the next question - how can one fix the 2048x2048 limit ?
check out this thread:
http://marc.theaimsgroup.com/?t=10670319530
Around 11 o'clock on Feb 28, Vladimir Dergachev wrote:
> I agree. For example, on my Dell notebook the graphics card is not
> reinitialized properly on return from resume. At some point I'll get
> bothered enough to write code that does it.
# vbetool post
Run from your suspend script while on
On Mon, 28 Feb 2005, Pavel Machek wrote:
Hi!
I think that the driver is the "chief" here and the one to know what to
do with the cards it drives. It can detect a non-POSTed card and deal
with it.
What about the x86 case of VGA devices that run without a driver being
loaded? Do we force people to l
By default r300_demo and r300_driver have tiling enabled at 16x16 pixel
squares, in fact the card should come up with this on by default..
Now on to the next question - how can one fix the 2048x2048 limit ?
check out this thread:
http://marc.theaimsgroup.com/?t=10670319533&r=1&w=2
another optio
On Mon, 28 Feb 2005 10:05:28 -0500 (EST), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
>
> >>>
> >>> tiling is disabled by default on r3/4xx cards so it shouldn't affect
> >>> you. someone needs to figure out how to properly enable it on r3/4xx
> >>> cards (for both 2d and 3d). Once it is figur
Hi!
> > I think that the driver is the "chief" here and the one to know what to
> > do with the cards it drives. It can detect a non-POSTed card and deal
> > with it.
>
> What about the x86 case of VGA devices that run without a driver being
> loaded? Do we force people to load an fbdev driver to
tiling is disabled by default on r3/4xx cards so it shouldn't affect
you. someone needs to figure out how to properly enable it on r3/4xx
cards (for both 2d and 3d). Once it is figured out it should provide
a nice boost in performance.
Alex,
Could you explain to me what tiling is ? I thought
On Mon, 28 Feb 2005 01:05:43 -0500 (EST), Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
> >> Hopefully, the updated drm will allow me to stay in X for a while
> >> without encountering the
> >> "WaitForSomething(): select: errno=22" error I was having with the
> >> current drm.
> >>
> >> One questi
> Aapo Tahkola wrote:
>> Ok. I said that this bug doesnt exist and it was just my problem ...
>> I changed my mind as it appeared again after rebuilding just about
>> everything and tracked it down after long battle. This was caused by
>> missing curly braces around texcoord VAP input configuration
Hi,
Nice catch!
Aapo Tahkola wrote:
Ok. I said that this bug doesnt exist and it was just my problem ...
I changed my mind as it appeared again after rebuilding just about
everything and tracked it down after long battle. This was caused by
missing curly braces around texcoord VAP input configurati
20 matches
Mail list logo
