Inspiring

Why is Oculus writing a (non-VR) general purpose library?

30 replies
6822 views

Let me preface this by saying that I love my Rift, and I think that Oculus VR has a big future ahead of it. But its becomeing clear to me that OVR is spending valuable developer time writing general purpose classes. These classes duplicate existing free functionality.

Some examples:

OVR_Atomic.h - A set of classes for atomic operations against types

OVR_String.h - A basic String class

OVR_List.h - A basic linked list container class

OVR_Array.h - A basic linked vector container class

Basically everything in the LibOVR/Src/Kernel subdirectory is an example of this. I'm really concerned about it, because every hour spent on extending this is an hour not working on VR specific stuff, or features the community wants. Writing a string class or a linked list class is something you do in a job interview, not in an SDK, or any kind of production code. These are solved problems. Right now almost half of your total lines of code in the SDK are in the Kernel subdirectory, implying almost half your development time has been spent doing stuff no one outside of OVR cares about or is ever going to use.

I've honestly tried to hold my tongue about this, but the lastest SDK version shows that OVR is not only not slowing or reversing this trend, but appears to be doubling down with the new inclusion of a JSON parser, again written from scratch and again, increasing the internal dependence on other duplicated functionality, like the String class. How much earlier would the Linux port have been released if writing a JSON parser you'd simply written #include <boost/property_tree/json_parser.hpp> or instead of writing a string class you'd written #include <string>.

I really can't understand why OVR would be doing this unless it's developers are either unaware of Boost and the Standard Template Library, or have a serious case of not-invented-here syndrome. If it's the former, I suggest you do a little bit of reading up, but if, as I suspect, it's the latter, I suggest you get over it and start focusing on your core deliverables, not these diversions. I know it's actively impeding my integration of your software, and I suspect I'm not alone.

Show previous replies

D

densohax

Up and Coming

"jherico" wrote:
"geekmaster" wrote:
This thread has been a fascinating read. I too am doing the "Pi" thing. But I am going native (no OS) and using the GPU assembler (mostly reverse-engineered). Let the CPU just be a little GPIO coprocessor for the "real" computer in the Pi (the GPU)...
;)

That sounds pretty ambitious. Is there a reason you're not using Open GLES?

I believe he refered to using the GPU as a Stream processor for logic and not necessarily for graphical purposes. Like CUDA or OpenCL for example..

G

geekmaster

Up and Coming

"densohax" wrote:
I believe he refered to using the GPU as a Stream processor for logic and not necessarily for graphical purposes. Like CUDA or OpenCL for example..

Yeah, kinda. This:

"
Pootling around the Raspberry Pi forums late last night, I found something that rightfully shouldn’t exist. It’s a two-player chess game for the Pi – nothing so unusual there – written in assembly language, with no OS. Which is highly unusual.

"
"https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV-Kernels-under-Linux. ...
Videocore IV Community and Resources:

mm120's https://github.com/mm120/binutils-vc4/tree/vc4 repo is a work in progress adding videocore support to gnu binutils. It seems to be coming along nicely, and I will add some prebuilt binaries for Linux, OSX, Windows and RPi/Linux to github soon.

thubble's https://github.com/thubble/vcdevtools, https://github.com/thubble/videocore-elf-dis and https://github.com/thubble/binutils-vc4/tree/vc4 repos cover a videocore disassembler (C#), a preliminary assembler (C) and a bootloader (asm) that can receive code via UART. thubble is particularly focussed on documenting the instructions of the integer vector processing unit (PPU).

mgottschlag's https://github.com/mgottschlag/resim and https://github.com/mgottschlag/vctools repos are focussed on tools and information for reverse engineering the bcm2835's hardware registers and functional blocks. mgottschlag is generating register access traces by simulating code sequencies on a remote computer running a videocore emulator and forwarding them to a real bcm2835 running a small monitor.

phire's https://github.com/phire/llvm repo contains some early work on porting llvm to videocore, and is ripe for someone to grab and continue.

dwelch67's https://github.com/dwelch67/rpigpu repo is focussed on bare metal samples written in C. dwelch67 has two experimental binary translators targeting the videocore instruction set. one translates mips to videocore and the other translates arm thumb to videocore.
"
... This is not beginner stuff in any way, this is not a generic C compiler for the Raspberry Pi gpu. This is for people are capable of writing their programs in both thumb MACHINE CODE and gpu MACHINE CODE but want to save some time. ... If you do nothing else check out the tinyasm/asm.c file in the above repo. It a mixture of pure genius and mad scientist. I love it, I may model all of my assemblers after that in the future. I have taken it and ripped out everything but the emits to create the doemit.c program I use to aid in the translation.

And much more... ;)
"jherico" wrote:
That sounds pretty ambitious. Is there a reason you're not using Open GLES?

"Ambition" is my middle name. I knew as a child that I had enough projects to last six lifetimes, and that was assuming that I would live to 120... :lol:

And besides, I plan to play with the GLES 2.0 stuff too, ya know? :D

I just need other people to help me play with this stuff. Not enough hours in a day for just one person. :o

EDIT: As you can probably guess by now, I do not plan to use STL or Boost, and perhaps not even a C compiler for that matter... ;)

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

M

MrGeddings

Up and Coming

that and i think they want as many people as possible to be able to use the code so using it in some code that is "only" for VR might limit its applications for other things.

J

jhericoAuthor

Inspiring

"geekmaster" wrote:

"Ambition" is my middle name. I knew as a child that I had enough projects to last six lifetimes, and that was assuming that I would live to 120... :lol:

Well good luck. I just now got my Rift reporting back sensor data on my Raspberry Pi. I'm planning on integrating the Rift into a costume I'm making for Penny Arcade Expo Prime, so I've got a hard deadline on getting it all working.

Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action

G

geekmaster

Up and Coming

"jherico" wrote:
Well good luck. I just now got my Rift reporting back sensor data on my Raspberry Pi. I'm planning on integrating the Rift into a costume I'm making for Penny Arcade Expo Prime, so I've got a hard deadline on getting it all working.

I used the signal11 library on my RasPi, and before that the first release of the nsb mini SDK. They both worked fine on the Pi (but the nsb lib did not work on my Linux Mint, which is part of why I switched to signal11). I am decoding my own HID packets, and not bothering with HID reports other than requesting raw data.

Which libraries are you using to obtain the Rift sensor data on your RasPi?

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

J

jhericoAuthor

Inspiring

"geekmaster" wrote:
Which libraries are you using to obtain the Rift sensor data on your RasPi?

I'm using the same stuff that's used for the linux stuff in the SDK (both mine and the official one). Udev for querying the hardware for the appropriate hidraw device, and then a standard file descriptor against /dev/hidrawN with ioctl calls for getting and setting features. As with my normal linux stuff I'm using Boost to handle asynchronous IO and timer events. All of the code is here: https://github.com/jherico/OculusSDK/tree/rasp_pi/LibSimpleOVR and my test code that I ran last night looks like this:

void callback(const unsigned char * bytes, unsigned int length) {
    for (int i = 0; i < length; ++i) {
        cout << hex << setfill('0') << setw(2) << (int)bytes[i];
    }
    cout << endl;
}

int main(int argc, char ** argv) {
    ovrInit();
    HANDLE_SENSOR * devices = ovrEnumerateSensors();
    if (*devices) {
        cout << "Found sensor" << endl;
    }
    // just use the first sensor
    HANDLE_SENSOR device = *devices;
    DisplayInfo di; memset(&di, 0, sizeof(DisplayInfo));
    ovrGetDisplayInfo(device, &di);
    ovrSensorRegisterCallback(device, &callback);

    usleep(10 * 1000 * 1000);
    ovrShutdown();
}

Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action

J

jhericoAuthor

Inspiring

"geekmaster" wrote:
"densohax" wrote:
I believe he refered to using the GPU as a Stream processor for logic and not necessarily for graphical purposes. Like CUDA or OpenCL for example..

Yeah, kinda.

I was hoping there would be an OpenCL implementation on the Pi, but apparently it's not forthcoming. At least you can apparently do a significant amount of what you'd want to do using GLES:

http://raspberrypi.stackexchange.com/questions/41/can-i-use-the-gpu-for-calculations

Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action

A

Anonymous

in my opninion: writing basic functions where similar ones already exist might seem stupid and unnecessarily time consuming at first but i think at the end it might pay off ! if in future oculus has any problems with basic functions where else they would have to do bigger work arounds or ugly, hacky code this can become handy by simply making small changes in their functions. The Oculus Team probably wants to do bigger stuff and extend their SDK so on higher level coding for them will become hard enough to still worry about basic crap

J

jhericoAuthor

Inspiring

"Maddy25" wrote:
if in future oculus has any problems with basic functions where else they would have to do bigger work arounds or ugly, hacky code this can become handy by simply making small changes in their functions.

The problem with that is that the built in string, vector and list functions are extremely[/] well documented, tested and understood, so your hypothetical problem is much more likely to occur in the Oculus custom versions of them rather than in the more widely used versions. Further, if they encounter a problem in the future that they could solve simply by tweaking one of their existing classes, any such change the behavior of the class could result in breaking all the stuff that's currently using it.

There are lots of things you can try to justify in development processes with hypotheticals, but it almost always boils down to premature optimization.

What is far more likely is that the developers are already familiar with their code from Scaleform and it's easier to continue working with that than to take time to learn something new, like how to use the STL equivalents.

Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action

G

geekmaster

Up and Coming

"jherico" wrote:
I was hoping there would be an OpenCL implementation on the Pi, but apparently it's not forthcoming. At least you can apparently do a significant amount of what you'd want to do using GLES:

http://raspberrypi.stackexchange.com/questions/41/can-i-use-the-gpu-for-calculations

As I mentioned in my "TL;DR" post above:

"
... Breaking News it is now possibly to use VideoCore Kernels from Userland / Linux, see https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV-Kernels-under-Linux. ...

So it seems that progress is being made in providing an entry into OpenCL-like features on the RasPi. ;)

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Get Help

Sign up

Login with SSO

Login to the community

Login with SSO