Active Topics
-
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 7 hrs, 8 mins ago -
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 11 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 23 hrs ago -
n770 youtube video (0)
to General by nmdv - 5 days, 23 hrs ago - more...
| The Following 2 Users Say Thank You to lardman For This Useful Post: | ||
|
2011-01-14
, 15:34
|
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#1882
|
Originally Posted by lardman
While I guess the user-space OpenGL binaries would work (as the PowerVR chipset is the same) assuming the kernel module presents the same interface and api to these libraries, there is the problem that I can't seem to find a kernel module for the PowerVR hardware in the Samsung Hummingbird chip in the Tab.
Now the only thing to persuade myself of is that the Pandaboard OpenGL binaries will happily drive the same SGX 540 in the Tab.
This might not be the end of the world as we have an existing implementation for the SGX 540 in the OMAP 4 in the Pandaboard, it will require work to be done to implement such a driver (and I don't know quite how much.)
| The Following 2 Users Say Thank You to lardman For This Useful Post: | ||
 |
|
2011-01-14
, 16:00
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#1883
|
Originally Posted by lardman
Very interesting stuff, I'm following your thoughts eagerly.
While I guess the user-space OpenGL binaries would work (as the PowerVR chipset is the same) assuming the kernel module presents the same interface and api to these libraries, there is the problem that I can't seem to find a kernel module for the PowerVR hardware in the Samsung Hummingbird chip in the Tab.
This might not be the end of the world as we have an existing implementation for the SGX 540 in the OMAP 4 in the Pandaboard, it will require work to be done to implement such a driver (and I don't know quite how much.)
Are you implying that the Tab kernel has the 540 drivers baked in, or are you having trouble locating them in the Tab sources?
|
|
2011-01-14
, 18:34
|
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#1884
|
The Tab kernel drivers must exist in binary form in the Android images, but I can't find any source for them. Likewise the binary user-space libraries that use the SGX hw (up to and including the actual OpenGL library) will exist in the Android image, and it's nigh on impossible that source would ever be released for these.
We have an open source kernel driver for the OMAP4 Pandaboard and closed source binary user-space libs, so the question is really whether a kernel driver can be developed for the Tab that uses the same interface as the Pandora user-space libraries.
Last edited by lardman; 2011-01-14 at 18:40.
We have an open source kernel driver for the OMAP4 Pandaboard and closed source binary user-space libs, so the question is really whether a kernel driver can be developed for the Tab that uses the same interface as the Pandora user-space libraries.
Last edited by lardman; 2011-01-14 at 18:40.
| The Following 2 Users Say Thank You to lardman For This Useful Post: | ||
|
|
2011-01-14
, 19:15
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#1885
|
Sounds challenging.
However, if the kernel sources are available and are made to work with the ABI of the module binary, wouldn't it be possible to transplant the portion of the kernel responsible for the SGX into a fresh kernel tree? I suspect that the interface would be the only difference as the module would contain the necessary graphics code.
I can see this being a problem if the module is somehow compiled differently, and would require that the Android module receive special treatment from more traditional builds.
However, if the kernel sources are available and are made to work with the ABI of the module binary, wouldn't it be possible to transplant the portion of the kernel responsible for the SGX into a fresh kernel tree? I suspect that the interface would be the only difference as the module would contain the necessary graphics code.
I can see this being a problem if the module is somehow compiled differently, and would require that the Android module receive special treatment from more traditional builds.
| The Following User Says Thank You to Capt'n Corrupt For This Useful Post: | ||
|
|
2011-01-14
, 21:27
|
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#1886
|
Certainly, I need to find a Tab Android image and take a look at the SGX kernel module and see what it does, and see if I could get it to work with the Pandaboard userspace libraries.
The kernel module itself is quite simple, it's generally just a gateway to the PowerVR hardware which is then controlled by commands from the userspace libraries.
Being relatively simple, it would probably be possible to adapt the Pandaboard kernel module source (and then by definition, hopefully, the complex and no-way-it-will-be-opened user space libraries should work with it as the chipset is the same).
It would, however, be all round easier if Samsung would just release a set of user space binaries (source is realistically too much to hope for) and source for the kernel module so that we can move on and be able to use the hardware.
I've emailed them to ask if they would be willing to do this to get Meego running on the Tab, I'll let you know how I get on.
The kernel module itself is quite simple, it's generally just a gateway to the PowerVR hardware which is then controlled by commands from the userspace libraries.
Being relatively simple, it would probably be possible to adapt the Pandaboard kernel module source (and then by definition, hopefully, the complex and no-way-it-will-be-opened user space libraries should work with it as the chipset is the same).
It would, however, be all round easier if Samsung would just release a set of user space binaries (source is realistically too much to hope for) and source for the kernel module so that we can move on and be able to use the hardware.
I've emailed them to ask if they would be willing to do this to get Meego running on the Tab, I'll let you know how I get on.
| The Following 4 Users Say Thank You to lardman For This Useful Post: | ||
|
|
2011-01-14
, 22:28
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#1887
|
Fantastic!
One thing worth consideration is that Android's libc (a likely linked lib component of any dynamic userland binary) is not the vanilla libc, but the stripped down Bionic (and maybe a modified version at that). Either way, this may be useful information when trying to spark the PVR libs that may be compiled against such code. The dl name may mask the code origin, which is why I mention this, but it should be contained within Android sources.
One thing worth consideration is that Android's libc (a likely linked lib component of any dynamic userland binary) is not the vanilla libc, but the stripped down Bionic (and maybe a modified version at that). Either way, this may be useful information when trying to spark the PVR libs that may be compiled against such code. The dl name may mask the code origin, which is why I mention this, but it should be contained within Android sources.
|
|
2011-01-15
, 11:23
|
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#1888
|
Originally Posted by Capt'n Corrupt
I'd hope to just use the Pandaboard user-space libs (as the SGX hardware is the same and the kernel driver should abstract away any SOC differences, I'd hope!)
Fantastic!
One thing worth consideration is that Android's libc (a likely linked lib component of any dynamic userland binary) is not the vanilla libc, but the stripped down Bionic (and maybe a modified version at that). Either way, this may be useful information when trying to spark the PVR libs that may be compiled against such code. The dl name may mask the code origin, which is why I mention this, but it should be contained within Android sources.
| The Following 2 Users Say Thank You to lardman For This Useful Post: | ||
|
|
2011-01-15
, 11:51
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#1889
|
Originally Posted by lardman
Hopefully this works. Trying to find detailed info on either are like pulling teeth, and yes, here's hoping that the module can be used across the line.
I'd hope to just use the Pandaboard user-space libs (as the SGX hardware is the same and the kernel driver should abstract away any SOC differences, I'd hope!)
But with a company as protective over it's IP as Imagination, I wouldn't be surprised if there were slight incompatibilities between drivers. I remain optimistic, though.
Keep us posted!
| The Following User Says Thank You to Capt'n Corrupt For This Useful Post: | ||
|
|
2011-01-15
, 12:08
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#1890
|
@all,
I'm just learning this, which has seemed to escape the public knowledge..
DISCLAIMER:I've gotten this info from Wikipedia, so you know, it could be dead wrong:
http://en.wikipedia.org/wiki/List_of...ies5_.28SGX.29
The Galaxy Tab's SoC is the Samsung S5PC110, which is 1GHz and has the SGX540. However, what you may not know is that the SGX540 on this SoC is clocked to 100MHz and can push 20M polygons with a pixel fill rate (theoretical) of 0.5G .
http://www.samsung.com/au/smartphone...fications.html
The Galaxy S's SoC is the Samsung S5PC111 which is 1GHz and also has the SGX540. However, this SoC's SGX is clocked to 200MHz and can push 35M polygons with a pixel fill rate of 1G. A *very* significant performance leap over the Tab.
http://www.samsung.com/au/smartphone...fications.html
The bottom line? The Galaxy S is a stronger performer graphically than the Galaxy Tab! I also means that while the Galaxy S is ahead of the famous iOS products, the Tab may not be, as the SGX535 is clocked at 200MHz and handles 28M polygons with a fill rate of 0.5G. This depends upon how high the core is clocked in the A4.
Somewhat disappointing. I would have hoped that the Tab, with a far larger battery, would have opted for the higher clocked GPU, especially since it has a higher res screen.
I'm just learning this, which has seemed to escape the public knowledge..
DISCLAIMER:I've gotten this info from Wikipedia, so you know, it could be dead wrong:
http://en.wikipedia.org/wiki/List_of...ies5_.28SGX.29
The Galaxy Tab's SoC is the Samsung S5PC110, which is 1GHz and has the SGX540. However, what you may not know is that the SGX540 on this SoC is clocked to 100MHz and can push 20M polygons with a pixel fill rate (theoretical) of 0.5G .
http://www.samsung.com/au/smartphone...fications.html
The Galaxy S's SoC is the Samsung S5PC111 which is 1GHz and also has the SGX540. However, this SoC's SGX is clocked to 200MHz and can push 35M polygons with a pixel fill rate of 1G. A *very* significant performance leap over the Tab.
http://www.samsung.com/au/smartphone...fications.html
The bottom line? The Galaxy S is a stronger performer graphically than the Galaxy Tab! I also means that while the Galaxy S is ahead of the famous iOS products, the Tab may not be, as the SGX535 is clocked at 200MHz and handles 28M polygons with a fill rate of 0.5G. This depends upon how high the core is clocked in the A4.
Somewhat disappointing. I would have hoped that the Tab, with a far larger battery, would have opted for the higher clocked GPU, especially since it has a higher res screen.
| The Following User Says Thank You to Capt'n Corrupt For This Useful Post: | ||
 |
| Tags |
| android envy, buzz..buzz buzz, core failure, crapdroid, galaxy fap, galaxy tab, ipad killer, samsung, tab trolls, tablet envy |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 20:09.
Looking at the pin out of the connector along with that FSA9480 USB device switch I mentioned earlier, it looks like the cable type (effected by changing values if resistors somewhere in there) can be used to signal the device (via the USB switch) what should happen.
The kernel source for the device indicates that USB OTG Host and client are supported, as is some sort of HDMI output, sound, etc., etc. More info on xda.
Now the only thing to persuade myself of is that the Pandaboard OpenGL binaries will happily drive the same SGX 540 in the Tab.