Will you support HDMI?
What sort of clock rate is this card going to have?
How much memory?
What resolutions will it support?
Low Power too?
Reasonable price?
What would that be?
"The Devil is in the Details."
-gc
On 12/07/2012 04:21 PM, "Ing. Daniel Rozsnyó" wrote:
I would suggest to keep in the subject :)
Make a graphics in steps like:
- framebuffer
- 2D compositing
- 2D drawing acceleration
- 3D
- low power optimization
Today it really has to be connected with PCIe, on FPGA you can get
even PCIe 2.0 in reasonable price.
It can be coded on a FPGA development kit and later price optimized to
include components which are really needed.
"Having focus is a key aspect for having succcess."
Daniel
On 12/07/2012 11:16 PM, Gregory Carter wrote:
So are you suggesting a Mali type SoC that can run Android games?
Sort of like selling a Android game console for google play so you can
play games on your big screen?
You know that might work for a revenue stream.
With an SoC in a box that connects to Googe Play, with maybe a pad
accessory and HDMI output you could sell those pretty cheap.
You could also use it for Netflix, Browse the Internet from the couch.
-gc
On 12/07/2012 04:06 PM, gary sheppard wrote:
I honestly think because of ARM's encroachment there is a window of
opportunity for a "PC" that is powered by something other than x86.
Keep in
mind Joe six pack has no clue what "chip" arch is inside. They just
care
about the internet, facebook, email, and a few games. With android and
ARM
making waves, we would do well to look into what it would take to
"port"
app's over to whatever arch we run with.
On the other hand if we were to run with OpenSPARC our most likely game
plan would be more University / Educationally oriented. That does not
mean
we should forgo a means to Port things like Steam and their Source
Engine.
Hey, everyone likes some kind of game :)
On Fri, Dec 7, 2012 at 1:51 PM, Gregory Carter <[email protected]>
wrote:
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/****<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<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>
**<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>
**<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>
**<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)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
