I am not a SoC expert but I think the general idea of a lot of these GPU
designs tie them to CPU's and whole memory infrastructure as well, which
makes the whole software end of things really a mess. Sending messages
to a Mali GPU in MIPS from a Intel BUS does not after thinking about
some of the comments here sound very well, efficient.
I think that would go for just about any chip infrastructure that is
integrated.
We really need something that is naked/bare and tied only to
PCI/Xpress. Which at the moment from what I can find ties us to Nvidia,
AMD or a chip that we make.
Certainly it is most efficient.
Perhaps we need a marketing plan instead? We could use my last idea,
however, we buy AMD chips, put them on boards and compete in the market
place and use the funds to build a open GPU.
Although, if AMD found out what we were doing with the profits, I think
they might get upset and probably sue us.
:-)
-gc
On 12/07/2012 03:33 PM, gary sheppard wrote:
Unless some one has an ARM Lic. perhaps either OpenRISC or OpenSPARC would
be a better starting place. While I do like the momentum of ARM the price
of admission might be prohibitive.
On Fri, Dec 7, 2012 at 1:04 PM, "Ing. Daniel Rozsnyó" <[email protected]>wrote:
These integrated GPU's are not available without the processor. And you
will have very hard time, to find one which has PCIe (and that would be
pcie host not device).
Putting a SoC on a PCIe card has no real benefit. You are probably trapped
in a recursion - and if you get again to the surface, you has to
acknowledge that you can do your work on the SoC itself. No need to put it
into another system.
Daniel
On 12/07/2012 10:00 PM, Gregory Carter wrote:
Well, what about the Mali GPU work being done right now?
http://www.malideveloper.com/**developer-resources/drivers/**
open-source-mali-gpus-linux-**kernel-device-drivers.php<http://www.malideveloper.com/developer-resources/drivers/open-source-mali-gpus-linux-kernel-device-drivers.php>
Seems like the source code is available, and at least one Linux desktop
at the moment is up on OpenGL ES, which might be a little more realistic
than a Ivy Bridge setup on a card. (Which people have written to me
that that is not really practical. Although they haven't spelled out
the specifics. :-)
OpenGL ES is supported by KDE 4.10 right now, or at least I think Kwin
builds and runs fine on it completely accelerated last time I looked.
Maybe a little Mali coprocessor to start would be a better idea to
getting a card out quickly to get a revenue stream for funding a open
architecture.
-gc
On 12/07/2012 02:06 AM, Dieter BSD wrote:
So how much interest is there in my idea of a graphics card
with a framebuffer and a socket to optionally add the future gpu?
Can we build one with existing off the shelf parts (that have
datasheets)?
Daniel writes:
I am interested, but my target is to pack it into a mini-pcie embedded
design, however I can live with the fact that it can be prototyped as a
standard PCIe card.
They make adapters to plug mini-pcie cards into PCIe slots.
1) Is a mini-pcie card large enough?
2) If we go mini-pcie, how do we handle the connections to the displays?
One idea I had awhile back was rather than have the OGP GPU chip
plug into a socket, put it on a mini-pcie card and then plug that
into the PCIe framebuffer card.
______________________________**_________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/**mailman/listinfo/open-graphics<http://lists.duskglow.com/mailman/listinfo/open-graphics>
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
______________________________**_________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/**mailman/listinfo/open-graphics<http://lists.duskglow.com/mailman/listinfo/open-graphics>
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
______________________________**_________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/**mailman/listinfo/open-graphics<http://lists.duskglow.com/mailman/listinfo/open-graphics>
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
