Installing OpenMW on a Raspberry Pi 2

[psi29a]

Status report.... it runs.

It is using the Gallium VC4 DRI driver over GLAMOR, not SWRAST.

There is currently no DXTN (S3TC) support in the VC4 driver. I'll send a message to Eric in a bit to see when he thinks it'll land.

Screenies of 2fps fun.

[sandstranger]

Is it osg or ogre gles 2 rendering ? And if it osg gles2 render , how it work without shaders ?

[psi29a]

OSG, I haven't tried ogre yet... but really no reason to, same results: all pink.

[sandstranger]

Lol ,It some kind of magic or this driver works on software OpenGL

[psi29a]

No, the VC4_dri.so is the open-source Mesa Gallium DRM OpenGL driver for X11 (Xorg) for the VC4 chipset found in the Raspberry Pi and Pi 2. It isn't a frame-buffer (proprietary) driver like on your mobile. This runs over GLAMOR, meaning it takes all X11 calls and translates them into OpenGL.

https://wiki.freedesktop.org/dri/VC4/

The VC4 itself supports up to OpenGL 2.1 and GLSL (ES) 1.2

It would be the same thing if someone wrote their own open-source OpenGL drive/moduler for whatever chipset runs in your mobile.

I just got an email back from Eric Anholt(formally of Intel, now a developer at Broadcom):

Do you know when support for the gl_ext_texture_compression_s3tc extension might arrive in the vc4 dri module? The reason I ask is that in several applications I've tested, as a developer, they are loading their assets (dxt1 and dxt3) and fail leaving me with the typical pink models[3].

We'd have to uncompress in software.

I also gave Dolphin-emu a try and it complained that it couldn't compile its shaders because of two reasons; no OpenGL 3.1 support and then again with no GLSL 1.3 support. I remember us talking about how VC4 can be pushed to OpenGL 2.1 and GLSL 1.2, is that the hard limit of to what the VC4 can support?

This is not even slightly GL 3.1 hardware.

So there you have it, no hardware s3tc support on the VC4. This means either 1) Eric implements a software (swrast) fallback for that extension or 2) We (OpenMW) supports s3tc decompression when the opengl extension doesn't exist.

Zini and Scrawl: May I create a feature bug for post 1.0?

https://code.google.com/r/silvester747- ... cs/s3tc.py
^-- software decompressor written in python.

[Chris]

So there you have it, no hardware s3tc support on the VC4. This means either 1) Eric implements a software (swrast) fallback for that extension or 2) We (OpenMW) supports s3tc decompression when the opengl extension doesn't exist.

Zini and Scrawl: May I create a feature bug for post 1.0?

https://code.google.com/r/silvester747- ... cs/s3tc.py
^-- software decompressor written in python.

Unless S3 (or whoever) releases its patents on the S3TC format, it can't be included in GPL code.

[psi29a]

Unless S3 (or whoever) releases its patents on the S3TC format, it can't be included in GPL code.

Which is a pity, but there are workarounds. We (or someone) can provide the decompressor as a plugin that gets pulled in at run-time. This is how Mesa (and others) get around the problem without exposing themselves to the liabilities.

Another MIT license software decompressor in C: libsquish which is contributed to by nvidia.
https://code.google.com/p/libsquish/

Another way to go is S2TC: https://en.wikipedia.org/wiki/S2TC

The S2TC reference implementation is also capable of decompressing S3TC compressed textures, but instead of implementing the patented aspects of the algorithm, the S2TC decompressor picks colors at random. S2TC was created to provide an alternative to S3TC for open source OpenGL implementations which are legally constrained from implementing patented algorithms.

[wareya]

>instead of implementing the patented aspects of the algorithm, the S2TC decompressor picks colors at random

Genius.

[psi29a]

I thought so as well...

More from Eric:

I noticed that VC4 exposes GL_OES_compressed_ETC1_RGB8_texture, which seems to be mandatory as of OpenGL 4.3 so we can use this for non-alpha textures across platforms. Would there be any way to expose additional compression extensions such as:

GL_ARB_texture_compression_bptc
GL_EXT_texture_compression_rgtc

or are these not directly supported by VC4 hardware?

Nope, only ETC1. (You can find HW documentation at https://www.broadcom.com/docs/support/v ... G100-R.pdf)

Note that the driver isn't currently doing ETC1, it just decodes to RGBA8888. I've got a branch for supporting it, but I haven't done the work to do validation for ETC1 yet so it's not merged.

[psi29a]

Neat trick for getting alpha-channel into an ETC1 compressed object. It requires that the texture is then used via a shader that does some tricks.

http://malideveloper.arm.com/resources/ ... -channels/