[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKb7UvhnOjNOg1TZwfW4eu0MmyrBewXOYgpnU25FWjgrupZTdg@mail.gmail.com>
Date: Wed, 11 Feb 2015 04:15:27 -0500
From: Ilia Mirkin <imirkin@...m.mit.edu>
To: lausgans@...il.com
Cc: dri-users@...ts.freedesktop.org, xorg@...ts.x.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: Video option for a big endian machine?
On Wed, Feb 11, 2015 at 3:53 AM, <lausgans@...il.com> wrote:
> Hello.
>
> I'm looking for a PCI or AGP video card that would work on a Linux port for a big endian architecture (HP PA-RISC). Unfortunately the stock video options (ATI FireGL X1 and X3) give an incredibly slow unaccelerated 2D due to failure to kickstart the command processor (radeon open source driver). Neither folks from linux-parisc@ nor from dri-devel@ camps know how to fix this.
>
> Are there any other options that should get a good accelerated 2D or better 3D and theoretically should work on a subj (big endian byte order, looks like coherent memory and all I/O is going through IOMMU chip)?
>
> How about nouveau or anything else on non-x86 arch? What people are using on POWER machines for example?
The current state of hardware-accelerated 2d/3d on big endian is a bit
of a mess. With nouveau, you can generally get older cards to work
(esp if you stick to 4K pages) -- by older I mean pre-G80 (nv50)
cards. A user recently tried to get a semi-modern (fermi) nvidia card
up and running, and ended up with messed up colors (the belief is that
the LUTs are being messed up, but it could be any number of issues). I
believe that ATI/AMD hardware, generally speaking, also works. IIRC
PA-RISC has some extra-special issues beyond being BE though. You can
get a used card for pretty cheap, you might give nouveau a try.
Moving to 3d-land (i.e. mesa), hw drivers used to work before mesa 9.2
or 9.1 or so, but then some changes went in to fix llvmpipe (software
3d implementation, using LLVM as a JIT) on big endian platforms which
cause byte-swapped textures in many cases on actual hw. Some
additional work was done to fix this, but I'm not sure what the status
is.
I think the biggest reason for this is that nobody actually has access
to BE CPU's anymore, especially not in conjunction with 16x PCIe slots
-- they tend to be server-class machines with little attention paid to
graphics. You just run VM's on them, and use llvmpipe to get that
fancy 3d compositor to work. I don't think any of the issues are
_that_ hard to fix, but very difficult to do so "blind".
-ilia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists