www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GDC & Pandaboard/QEMU & Framebuffer

reply "John A" <nospam some.com> writes:
Not sure where to post this; it's not a question, just some info.

I have created a set of pages here:

   http://arrizza.org/wiki/index.php/Dlang

with instructions which include:
   - how to create a GDC cross-compiler using crosstool-ng
   - how to create some sample applications to test out GDC
   - how to create a sample app that writes to the framebuffer via 
GDC
   - how to set up and run these apps on QEMU
   - how to run the same apps on a Pandaboard

There is nothing new here. Others have written it already, some 
of which worked as advertised for me, some didn't. I've just 
gathered it up, tried it out and wrote down very specific 
instructions about what I needed to do to get it to work. 
Hopefully it works well for you.

Note I use Ubuntu 12.04 for everything, so these pages won't help 
Windows folks.

John
Oct 05 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Monday, 6 October 2014 at 04:39:03 UTC, John A wrote:

 Not sure where to post this; it's not a question, just some 
 info.

 I have created a set of pages here:

   http://arrizza.org/wiki/index.php/Dlang

 with instructions which include:
   - how to create a GDC cross-compiler using crosstool-ng
   - how to create some sample applications to test out GDC
   - how to create a sample app that writes to the framebuffer 
 via GDC
   - how to set up and run these apps on QEMU
   - how to run the same apps on a Pandaboard

 There is nothing new here. Others have written it already, some 
 of which worked as advertised for me, some didn't. I've just 
 gathered it up, tried it out and wrote down very specific 
 instructions about what I needed to do to get it to work. 
 Hopefully it works well for you.

 Note I use Ubuntu 12.04 for everything, so these pages won't 
 help Windows folks.

 John


Nice, I have ldc working at pretty much the same level on 
linux/arm, tested on a Cubieboard2.  Have you tried running any 
of the druntime/phobos unit tests?  All but two modules of 
druntime, as of the dmd 2.066 release, pass for me, while only 
three modules pass from phobos.  I'll put up instructions for 
cross-compiling with ldc once I have more of it working, as 
cross-compiling with ldc is easier.
Oct 06 2014
next sibling parent reply "John A" <nospam some.com> writes:
 Nice, I have ldc working at pretty much the same level on 
 linux/arm, tested on a Cubieboard2.  Have you tried running any 
 of the druntime/phobos unit tests?


No, it's on my todo list.

One thing I'll do first is see if I can modify Derelict3 to be 
Phobos free. If so the opengl3 library will probably be more 
useful to me. There might even be a mid-point where only a 
portion of Phobos needs porting.


 All but two modules of druntime, as of the dmd 2.066 release, 
 pass for me, while only three modules pass from phobos.  I'll 
 put up instructions for cross-compiling with ldc once I have 
 more of it working, as cross-compiling with ldc is easier.


Cool. All useful work in the end...
Oct 10 2014
parent reply Mike Parker <aldacron gmail.com> writes:
On 10/11/2014 2:27 PM, John A wrote:


 One thing I'll do first is see if I can modify Derelict3 to be Phobos
 free. If so the opengl3 library will probably be more useful to me.
 There might even be a mid-point where only a portion of Phobos needs
 porting.


I would recommended using the packages from DerelictOrg [1] rather than 
Derelict 3, as the latter is no longer maintained.


[1] https://github.com/DerelictOrg

---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
Oct 11 2014
parent reply "John A" <nospam some.com> writes:
 I would recommended using the packages from DerelictOrg [1] 
 rather than Derelict 3, as the latter is no longer maintained.


I did get Derelict3 to compile. I had to use a Makefile instead 
of dub but all the files compiled cleanly with no warnings. I did 
not add any unit tests as of yet, so I don't know if anything 
runs.

I took your recommendation and cloned from DerelictOrg. It failed 
to compile in a couple of files: arb.d and ext.d. All the 
failures were due to the same error, e.g.:

source/derelict/opengl3/arb.d:933: error: user defined attributes 
cannot appear as postfixes

The original line in Derelict3 is:
   private __gshared bool _ARB_depth_buffer_float;
   bool ARB_depth_buffer_float()  property { return 
_ARB_depth_buffer_float; }

The line in DerelictOrg is:
   private __gshared bool _ARB_depth_buffer_float;
   bool ARB_depth_buffer_float()  nogc nothrow  property { return 
_ARB_depth_buffer_float; }
Oct 12 2014
parent reply Mike Parker <aldacron gmail.com> writes:
On 10/12/2014 8:08 PM, John A wrote:


 I took your recommendation and cloned from DerelictOrg. It failed to
 compile in a couple of files: arb.d and ext.d. All the failures were due
 to the same error, e.g.:

 source/derelict/opengl3/arb.d:933: error: user defined attributes cannot
 appear as postfixes

 The original line in Derelict3 is:
    private __gshared bool _ARB_depth_buffer_float;
    bool ARB_depth_buffer_float()  property { return
 _ARB_depth_buffer_float; }

 The line in DerelictOrg is:
    private __gshared bool _ARB_depth_buffer_float;
    bool ARB_depth_buffer_float()  nogc nothrow  property { return
 _ARB_depth_buffer_float; }


That means you're using an older version of the D frontend and I didn't 
take that into account when I added  nogc to the extension modules. A 
bugfix release is imminent.

For the curious, to get backward-compatible nogc support into Derelict, 
I've implemented it as a UDA for versions less than 2.066 of the D 
frontend (see derelict.util.system). Until recently, it compiled fine on 
pre-2.066, but when I applied it to the property functions in the 
extension modules, I had no idea that UDAs could not be postfixes and 
that it would break on pre-2.066.

I'm curious about the rationale behind allowing built-in attributes as 
postfixes but not UDAs. I'll see if it's in the docs, but if not, I'd 
like to know what it is. On the surface, it seems unintuitive to 
distinguish between the two.

---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
Oct 12 2014
parent reply Mike Parker <aldacron gmail.com> writes:
On 10/12/2014 9:45 PM, Mike Parker wrote:

 On 10/12/2014 8:08 PM, John A wrote:


 I took your recommendation and cloned from DerelictOrg. It failed to
 compile in a couple of files: arb.d and ext.d. All the failures were due
 to the same error, e.g.:

 source/derelict/opengl3/arb.d:933: error: user defined attributes cannot
 appear as postfixes

 The original line in Derelict3 is:
    private __gshared bool _ARB_depth_buffer_float;
    bool ARB_depth_buffer_float()  property { return
 _ARB_depth_buffer_float; }

 The line in DerelictOrg is:
    private __gshared bool _ARB_depth_buffer_float;
    bool ARB_depth_buffer_float()  nogc nothrow  property { return
 _ARB_depth_buffer_float; }




Fixed in master. Tag 1.0.10 for those using DUB.


---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
Oct 12 2014
parent reply "John A" <nospam some.com> writes:
 Fixed in master. Tag 1.0.10 for those using DUB.


Just did a git pull and recompile. It built clean. Mike thanks 
for the very quick response!

Next step for me, is to create a small opengl test app:
- does it cross-compile (on Ubunutu)?
- does it run in QEMU?
- does it run on a Pandaboard?

After that, I'll try the derelict gflw and see how that goes...


John
Oct 12 2014
parent reply "John A" <nospam some.com> writes:
 Next step for me, is to create a small opengl test app:
 - does it cross-compile (on Ubunutu)?
 - does it run in QEMU?
 - does it run on a Pandaboard?


Here's the result:
DerelictGL3 and DerelictUtil cross-compiles ok with no gdc-arm 
failures.

On the other hand, a very simple app has linker errors:

import derelict.opengl3.gl3;
void main()
   {
   // DerelictGL3.load();
   // DerelictGL3.reload();
   printf("Start opengl: version %s\n", DerelictGL3.loadedVersion);
   }

I'm using -nophoboslib so there are linker errors related to 
phobos. If I don't use -nophoboslib I still get errors:

make testgl3
/home/arrizza/x-tools/arm-cortexa9_neon-linux-gnueabihf/bin/arm-cortexa9_neon
linux-gnueabihf-gdc 
-I./DerelictUtil/source -I./DerelictGL3/source -Llib  testgl3.d 
-o opengl3
/tmp/ccSSbl9j.o: In function `_Dmain':
testgl3.d:(.text+0x40): undefined reference to 
`_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
testgl3.d:(.text+0x44): undefined reference to 
`_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
testgl3.d:(.text+0x58): undefined reference to 
`_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
testgl3.d:(.text+0x5c): undefined reference to 
`_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
/tmp/ccSSbl9j.o:(.data+0xc): undefined reference to 
`_D8derelict7opengl33gl312__ModuleInfoZ'
collect2: error: ld returned 1 exit status
make: *** [testgl3] Error 1


I was stuck, so I started on a different front. I created a 
variant of the framebuffer test (in C for now) that sets every 
pixel in the framebuffer while I kept track of the time. The 
results are interesting. In QEMU:
  ./fbrate
  time 1140000 11ms 90 fps

on the Pandaboard:
  ./fbrate
  time 40000 4ms 250 fps

(that's with -03 btw).

The idea is that I can now convert this to D and see what the 
frame rate is then.

But before I did, I tried to see if mouse events could be 
captured in a D app. I found out the QEMU distro has mev in it 
and so that was an even simpler first step. If that works, I 
would then find the (open) source code for mev and convert that 
to D. Unfortunately, it didn't work. The mouse capture in my 
version of QEMU is not working like I expect and so I don't see 
any mouse events coming out of QEMU. Haven't tried mev on the 
Pandaboard yet.

Any advice?
Oct 21 2014
parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 22 Oct 2014 06:26:56 +0000
schrieb "John A" <nospam some.com>:


 Next step for me, is to create a small opengl test app:
 - does it cross-compile (on Ubunutu)?
 - does it run in QEMU?
 - does it run on a Pandaboard?


 
 Here's the result:
 DerelictGL3 and DerelictUtil cross-compiles ok with no gdc-arm 
 failures.
 
 On the other hand, a very simple app has linker errors:
 
 import derelict.opengl3.gl3;
 void main()
    {
    // DerelictGL3.load();
    // DerelictGL3.reload();
    printf("Start opengl: version %s\n", DerelictGL3.loadedVersion);
    }
 
 I'm using -nophoboslib so there are linker errors related to 
 phobos. If I don't use -nophoboslib I still get errors:
 
 make testgl3
 /home/arrizza/x-tools/arm-cortexa9_neon-linux-gnueabihf/bin/arm-cortexa9_neon
linux-gnueabihf-gdc 
 -I./DerelictUtil/source -I./DerelictGL3/source -Llib  testgl3.d 
 -o opengl3
 /tmp/ccSSbl9j.o: In function `_Dmain':
 testgl3.d:(.text+0x40): undefined reference to 
 `_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
 testgl3.d:(.text+0x44): undefined reference to 
 `_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
 testgl3.d:(.text+0x58): undefined reference to 
 `_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
 testgl3.d:(.text+0x5c): undefined reference to 
 `_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
 /tmp/ccSSbl9j.o:(.data+0xc): undefined reference to 
 `_D8derelict7opengl33gl312__ModuleInfoZ'
 collect2: error: ld returned 1 exit status
 make: *** [testgl3] Error 1
 


You also have to link against DerelictGL3 and maybe DerelictUtil:
-lDerelictGL3 -lDerelictUtil
Oct 22 2014
parent reply "John A" <nospam some.com> writes:
On Wednesday, 22 October 2014 at 07:49:24 UTC, Johannes Pfau 
wrote:

 You also have to link against DerelictGL3 and maybe 
 DerelictUtil:
 -lDerelictGL3 -lDerelictUtil


Sorry for the confusion.
When I compile DerelictGL3 and DerelictUtil, I create archives 
libopengl3.a and libutil.a in a local 'lib' directory.

And when I add to the compilation line:
     -L./lib -lopengl3 -lutil

I get the same link errors:

$ make testgl3
/home/arrizza/x-tools/arm-cortexa9_neon-linux-gnueabihf/bin/arm-cortexa9_neon
linux-gnueabihf-gdc 
-I./DerelictUtil/source -I./DerelictGL3/source -Llib -lopengl3 
-lutil testgl3.d -o opengl3
/tmp/ccLpFyC8.o: In function `_Dmain':
testgl3.d:(.text+0x40): undefined reference to 
`_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
testgl3.d:(.text+0x44): undefined reference to 
`_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
testgl3.d:(.text+0x58): undefined reference to 
`_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
testgl3.d:(.text+0x5c): undefined reference to 
`_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader'
/tmp/ccLpFyC8.o:(.data+0xc): undefined reference to 
`_D8derelict7opengl33gl312__ModuleInfoZ'
collect2: error: ld returned 1 exit status
make: *** [testgl3] Error 1

Now here's the strange part. If I dump the symbols in the 
libopengl3.a's, the name above exists:
$ nm libopengl3.a | grep 
_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader
00000000 B 
_D8derelict7opengl33gl311DerelictGL3C8derelict7opengl33gl317DerelictGL3Loader

What am I missing?
Oct 22 2014
parent reply "John A" <nospam some.com> writes:
On Thursday, 23 October 2014 at 04:12:45 UTC, John A wrote:

 What am I missing?


To answer my own question, I put the source file in the wrong 
spot:

BAD:
$(ARM-GDC) $(INCDIR) -L$(LIBDIR) -lopengl3 -lutil -ldl testgl3.d 
-o testgl3

Good:
$(ARM-GDC) $(INCDIR) testgl3.d -L$(LIBDIR) -lopengl3 -lutil -ldl 
-o testgl3

Note: I had to add the -ldl because of unresolved dlopen, 
dlclose, etc. symbols.

Next up, running the ./testgl3 on QEMU causes a seg fault.
Oct 22 2014
parent "John A" <nospam some.com> writes:
 Next up, running the ./testgl3 on QEMU causes a seg fault.


Ok, it's working:

import derelict.opengl3.gl3;
extern (C) void printf(const char*, ...);
void main()
   {
   printf("Start opengl: \n");
   DerelictGL3.load();
   printf("Start opengl: version %d\n", DerelictGL3.loadedVersion);
   }

prints this in QEMU

   Start opengl:
   Start opengl: version 11

Next, create a triangle.
Oct 23 2014
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 6 Oct 2014 11:15, "Joakim via Digitalmars-d" <digitalmars-d puremagic.com>
wrote:

 On Monday, 6 October 2014 at 04:39:03 UTC, John A wrote:

 Not sure where to post this; it's not a question, just some info.

 I have created a set of pages here:

   http://arrizza.org/wiki/index.php/Dlang

 with instructions which include:
   - how to create a GDC cross-compiler using crosstool-ng
   - how to create some sample applications to test out GDC
   - how to create a sample app that writes to the framebuffer via GDC
   - how to set up and run these apps on QEMU
   - how to run the same apps on a Pandaboard

 There is nothing new here. Others have written it already, some of which




worked as advertised for me, some didn't. I've just gathered it up, tried
it out and wrote down very specific instructions about what I needed to do
to get it to work. Hopefully it works well for you.

 Note I use Ubuntu 12.04 for everything, so these pages won't help




Windows folks.

 John



 Nice, I have ldc working at pretty much the same level on linux/arm,


tested on a Cubieboard2.  Have you tried running any of the druntime/phobos
unit tests?  All but two modules of druntime, as of the dmd 2.066 release,
pass for me, while only three modules pass from phobos.  I'll put up
instructions for cross-compiling with ldc once I have more of it working,
as cross-compiling with ldc is easier.

At the last time I tested, all unittests and testsuite had been passing on
ARM.  There were a number of forward ported tests. And a few disabled (ie:
evaluation order of array operations differ between x86 and every other
architecture).

Iain.
Oct 10 2014
parent "John A" <nospam some.com> writes:
 At the last time I tested, all unittests and testsuite had been 
 passing on ARM.


Very nice. I'd like to replicate what you did. I haven't looked 
at Phobos at all yet, I'm working on getting opengl up and going 
first.

Any chance you can post instructions on exactly how you did that? 
Or point me to a url with those instructions? That would be 
fantastic!

Example of some things I think are relevant:
- I'm assuming gdc or did you use ldc instead? Which version of 
gdc+gcc?
- Was Phobos cross-compiled or did you compile on the devkit 
itself?
- If cross-compiled, for which ARM architecture (cortex a8, a9, 
M3, other)?
- What was the Host environment and it's configuration (linux vs 
Win)? If Linux, which version and did you have to install 
additional packages?
- Which repository and revision of Phobos did you use?
- Did you make any changes to the Phobos source to get it to 
compile?
- What were the exact command lines you used to compile Phobos? 
Can you supply a Makefile?
- What environment and configuration did you use to run the tests 
(Bare-metal, linux, qemu, etc.)? If not qemu, which devkit/board 
did you use (beagleboard, pandaboard, Raspberry PI, etc.)?
- What was the OS and configuration of the devkit?
- Did you have to update or install any additional libraries (.a 
or .so) onto the board?

Thanks in advance!
John
Oct 12 2014