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
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
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:
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
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
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 about
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
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.
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 head you
