Active Topics
-
Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 3 days, 23 hrs ago -
Handbook (2)
to Maemo 7 / Leste by teroyk - 4 days, 23 hrs ago - more...
|
2010-03-20
, 01:19
|
|
Posts: 12 |
Thanked: 1 time |
Joined on Feb 2010
|
#592
|
The ARM Linux Internet Platform of TI alredy have 3d and 2d accelerator ??
 |
|
2010-03-20
, 13:59
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#593
|
Back on topic...
So, we have the drivers and it kind-of works with the instructions posted by Stskeeps after flashing the provided Kernel (at least when starting from a "vanilla" Diablo flash on a N800).
One of the problems (as already mentioned) is that the content area does not get redrawn automatically (so we have to e.g. open the apps menu and close it to "reveal" the current content of the GL surface).
Do we know what needs to be done to fix this, and where the problem lies (in the binary-only code or in code we have access to)? I guess the redraw fix is the most important one to see if the artifacts are related to the redrawing or if there are some more issues.
So, we have the drivers and it kind-of works with the instructions posted by Stskeeps after flashing the provided Kernel (at least when starting from a "vanilla" Diablo flash on a N800).
One of the problems (as already mentioned) is that the content area does not get redrawn automatically (so we have to e.g. open the apps menu and close it to "reveal" the current content of the GL surface).
Do we know what needs to be done to fix this, and where the problem lies (in the binary-only code or in code we have access to)? I guess the redraw fix is the most important one to see if the artifacts are related to the redrawing or if there are some more issues.
| The Following 4 Users Say Thank You to thp For This Useful Post: | ||
 |
|
2010-03-20
, 17:54
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#594
|
Originally Posted by thp
We can even fix this in client applications, by just issuing a omapfb refresh after every egl swap buffers call. The issue is that we want to try not "going this way" since it would be bad from a performance PoV. Ideally the driver would be more aware of the n810 framebuffer setup.
Do we know what needs to be done to fix this, and where the problem lies (in the binary-only code or in code we have access to)? I guess the redraw fix is the most important one to see if the artifacts are related to the redrawing or if there are some more issues.
Basic idea is doing what the drivers call a WSEGL, which is something not unlike a "Windowing system abstraction layer" (aka we have currently a X11 one, a stub/fb one, and there's a Qt one around).
Last edited by javispedro; 2010-03-20 at 18:04.
| The Following 4 Users Say Thank You to javispedro For This Useful Post: | ||
|
|
2010-03-21
, 11:37
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#595
|
Originally Posted by javispedro
Do you have some example code or links to documentation on how to "manually" tell the omapfb to refresh?
issuing a omapfb refresh after every egl swap buffers call
|
|
2010-03-21
, 14:42
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#596
|
Originally Posted by thp
Something like....
Do you have some example code or links to documentation on how to "manually" tell the omapfb to refresh?
Code:
static int omapFd;
static void omapfbFlush()
{
struct omapfb_update_window u;
u.x = 80;
u.y = 60;
u.out_x = u.x;
u.out_y = u.y;
u.width = 720;
u.height = 420;
u.out_width = u.width;
u.out_height = u.height;
u.format = OMAPFB_COLOR_RGB565;
int res = ioctl(omapFd, OMAPFB_UPDATE_WINDOW, &u);
if (res != 0) {
printf("omapfb flush failed\n");
}
}
static void init() {
omapFd = open("/dev/fb0", O_RDWR);
if (omapFd < 0) {
printf("Failed to open omap fd\n");
}
}
static void fini() {
close(omapFd);
}
| The Following 5 Users Say Thank You to javispedro For This Useful Post: | ||
 |
|
2010-03-22
, 05:02
|
|
Posts: 138 |
Thanked: 375 times |
Joined on Aug 2009
@ Berlin
|
#597
|
Originally Posted by javispedro
Are there any hooks in the mbxaccess driver that will be called upon eglSwapBuffers?
We can even fix this in client applications, by just issuing a omapfb refresh after every egl swap buffers call. The issue is that we want to try not "going this way" since it would be bad from a performance PoV. Ideally the driver would be more aware of the n810 framebuffer setup.
omaplcd_ddc_swaptosystem and omaplcd_ddc_process_vsyncflip in omapfb_displayclass.c do look interesting, but unfortunately the functions that are called to register them with mbxaccess just don't (mbxaccess_RegisterDisplayClassDevice and mbxaccess_RegisterCmdProcList in mbxaccess_pvrclassjtable.c).
|
|
2010-03-22
, 16:38
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#598
|
Ok, so I tried to compile a example GL ES 1.x app in the DIABLO_ARMEL Scratchbox target, and compiling works with the included headers (from MBX_Linux_SDK/OVG/SDKPackage/Builds/OVG/LinuxMVX11ARMV6/Include) but when it comes to linking the object files with the libraries, I get the following error:
This has already been mentioned in an earlier post in this thread.
Do we need to obtain versions of the library for EABI version 4 (if so, can someone arrange this?) or can we somehow specify the EABI version in the DIABLO_ARMEL Scratchbox target?
Code:
ERROR: Source object libGLES_CM.so has EABI version 5, but target glestest has EABI version 4
Do we need to obtain versions of the library for EABI version 4 (if so, can someone arrange this?) or can we somehow specify the EABI version in the DIABLO_ARMEL Scratchbox target?
|
|
2010-03-22
, 17:40
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#599
|
Originally Posted by thp
Ah yes, forgout about this. For now, just binary edit the library file ELF header, replace 0x05 with 0x04 at offset 0x27 iirc. Ugly, but works.
Do we need to obtain versions of the library for EABI version 4 (if so, can someone arrange this?) or can we somehow specify the EABI version in the DIABLO_ARMEL Scratchbox target?Code:ERROR: Source object libGLES_CM.so has EABI version 5, but target glestest has EABI version 4
(Mer doesn't have this problem. The plan was indeed to get a EABI version 4 file, dunno what happened here)
|
|
2010-03-22
, 18:43
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#600
|
Originally Posted by javispedro
Thanks, that indeed let me compile and link the test app
For now, just binary edit the library file ELF header, replace 0x05 with 0x04 at offset 0x27 iirc. Ugly, but works.
The only problem now is that on my device, I don't get the chance to start anything (although it did work some days ago). The kernel modules load, I can create the new device nodes and set permissions and even start mbxdaemon, but "glinfo" and friends just hang with no output after starting them. dmesg tells me (this might or might not be related to the hanging):Code:
[ 131.757812] request OMAPLCD IRQ failedrequest OMAPLCD IRQ failed<1>Unhandled fault: external abort on non-linefetch (0x808) at 0x4002b024
Code:
import sys
for filename in sys.argv[1:]:
d = open(filename, 'rb').read()
nd = d[:0x27] + chr(4) + d[0x28:]
open(filename, 'wb').write(nd)
The GL-specific libraries I needed to pass to the linker were:
Code:
-lGLES_CM -lIMGegl -lsrv_um_1.1.35.630 -lEGL
| The Following 5 Users Say Thank You to thp For This Useful Post: | ||
Besides don't know how much hardware acceleration can help you with ordinary web rendering, not flash stuff, mind you.
Save the whales, feed the hungry, free the mallocs!