On Tue, 01 Mar 2005 01:09:28 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> 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
On Tue, 1 Mar 2005, 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 separately but just change the 2d/3d
eng
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
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
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
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
One question about tiling, will this cause any problems with the current r300
code? Or is it
something completely unrelated?
Well, Aapo has ported the patch and it worked on his computer - so it is
unlikely to cause problems. If it does we are still better off finding and
fixing the issue.
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 question about tiling, will this cause any problems with the current
r300 code? Or is it
something completely unrelated?
t
On Mon, 28 Feb 2005 16:38:05 +1100, Ben Skeggs <[EMAIL PROTECTED]> wrote:
> Vladimir Dergachev wrote:
>
> > [snip]
> >Thus, could everyone with changing they have not committed yet to
> > *DRM* driver but plan to please let me know ? Also any comments,
> > reservations, etc.
> >
> >One rea
Vladimir Dergachev wrote:
[snip]
Thus, could everyone with changing they have not committed yet to
*DRM* driver but plan to please let me know ? Also any comments,
reservations, etc.
One reason I am so eager for this is that there have been quite a
few fixes to the DRM driver, including t
Hi all,
Aapo Tahkola has made a merge of our current DRM driver and latest DRM
driver from freedesktop.org.
He asked me to commit this to R300 CVS (his Internet connection is a
bit slow for this) and I would like to do it. There will be quite a few
changes as the freedesktop.org + Aapo's
20 matches
Mail list logo