LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Accelerated graphics

Mon Sep 04, 2017 8:32 am

So I got asked to make an accelerated graphics sample which I have now done yeah old shaded triangle


Essentially I am going to see if I can follow along this series on the Pi in Baremetal ... should be fun :-)
http://www.mbsoftworks.sk/index.php?pag ... s&series=1
So sort of half way thru step 3 at the moment

So the question is probably to SteveD who asked for this which is how much of a write up do you want? Or are you happy to try and work out what all the code does (it's about 300 lines of C code) :-)

User avatar
Gavinmc42
Posts: 1517
Joined: Wed Aug 28, 2013 3:31 am

Re: Accelerated graphics

Tue Sep 05, 2017 4:53 am

Baremetal Pi versions :o

Peter Lemon's stuff is around step 3
I don't think anyone has done 3D in baremetal - step 4 - link anyone?
Starts getting interesting around step 6.

Take a bite and chew like mad, take the first step etc.
Big task you have set yourself. How to do OpenGL without OpenGL ;)
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Tue Sep 05, 2017 7:46 am

First code dump up ... it's horrible but lots to do
https://github.com/LdB-ECM/Raspberry-Pi ... ster/GLES2

Gavin you should be able to port that easily to Ultibo. Not sure what you are talking about with OpenGL, the VC4 has a GL pipeline. This gets back to sometimes comments on here with specifications make no sense to me.

At the moment I am trying to work out how I can future proof myself given we probably will have a new Pi coming with a VC5 (BCM7268) so I am looking at Eric Anholt's work closely. They already have a VC5 gallium driver done so the OpenGL path is fairly straight forward and they are saying the pipeline is OpenGL ES 3.1.
https://lists.freedesktop.org/archives/ ... 62087.html
The BCM7268 also has a MMU ^-^
https://anholt.github.io/twivc4/2017/08/28/twiv/

Looking at the Gallium driver code it's a strict GLES subset I can't find any legacy GL ARB desktop functions.

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Tue Sep 05, 2017 12:27 pm

I got stuck at the quad that is on the tutorial but it looks like the pipeline doesn't support GL_QUAD even though it's part of the OpenGL2.1 spec.

https://www.khronos.org/registry/OpenGL ... lBegin.xml

We are supposed to have Ten symbolic constants accepted:
GL_POINTS,
GL_LINES,
GL_LINE_STRIP,
GL_LINE_LOOP,
GL_TRIANGLES,
GL_TRIANGLE_STRIP,
GL_TRIANGLE_FAN,
GL_QUADS,
GL_QUAD_STRIP, and
GL_POLYGON

Well I can tell you the last 3 don't appear to work on the pipeline. No big deal just means I have to manually cut any GL_QUAD into two GL_TRIANGLES. Breaking a GL_POLYGON will require some sort of triangle tesselation. Anyhow will do quads first and move on.

I notice Eric Anholt mentions he turns GL_QUADS to GL_TRIANGLES on page 10 (https://lca2015.linux.org.au/slides/125/lca2015-rpi.pdf) but I didn't even think about them not being implemented or something strange with implementation. Anyhow lesson learned pushing on.

Code update quad working ... now onto tutorial 4 ... ohhh 3D nice

User avatar
Paeryn
Posts: 1673
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Accelerated graphics

Tue Sep 05, 2017 1:41 pm

LdB wrote:
Tue Sep 05, 2017 12:27 pm
I got stuck at the quad that is on the tutorial but it looks like the pipeline doesn't support GL_QUAD even though it's part of the OpenGL2.1 spec.

https://www.khronos.org/registry/OpenGL ... lBegin.xml

We are supposed to have Ten symbolic constants accepted:
GL_POINTS,
GL_LINES,
GL_LINE_STRIP,
GL_LINE_LOOP,
GL_TRIANGLES,
GL_TRIANGLE_STRIP,
GL_TRIANGLE_FAN,
GL_QUADS,
GL_QUAD_STRIP, and
GL_POLYGON

Well I can tell you the last 3 don't appear to work on the pipeline. No big deal just means I have to manually cut any GL_QUAD into two GL_TRIANGLES. Breaking a GL_POLYGON will require some sort of triangle tesselation. Anyhow will do quads first and move on.

I notice Eric Anholt mentions he turns GL_QUADS to GL_TRIANGLES on page 10 (https://lca2015.linux.org.au/slides/125/lca2015-rpi.pdf) but I didn't even think about them not being implemented or something strange with implementation. Anyhow lesson learned pushing on.
Why should quads and polygons be implemented in hardware on an OpenGLES device, OpenGLES doesn't have the concept of quads or polygons. Anyway 3D graphics hardware pretty much only deals in point, line and triangle primitives, anything else has to be broken down by the software driver into those primitives.
She who travels light — forgot something.

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Tue Sep 05, 2017 2:06 pm

https://en.wikipedia.org/wiki/VideoCore
At least the VideoCoreIV-AG100-R found e.g. in the Raspberry Pi 1, 2 and 3, is documented to fully support OpenGL ES 2.0 and OpenVG 1.1.
That is why it is supposed to do them do I really care it doesn't ... nope just strange. I haven't seen a GLES2 not do them.

Update: Ahh this explains it
https://www.khronos.org/opengl/wiki/Primitive
Warning: This section describes legacy OpenGL APIs that have been removed from core OpenGL 3.1 and above (they are only deprecated in OpenGL 3.0). It is recommended that you not use this functionality in your programs.
So they got dropped from spec so GLES2 doesn't have it anymore either then. Makes minimal GLES2 kind of strange it's got bits of 3.1, bits of 2.1 then but more compatible with later desktop OpenGL versions. I will have to remember that going forward as I know the OpenGL desktop specs really and probably going to get a couple of these. So note to self no more GL_QUADS in OpenGL one should not use them :-)

This is where unless you work with this stuff day in and day out it's a nightmare and they still exist on stock version Windows OpenGL 3.3 but I wonder if they are emulated.

Anyhow I need a view matrix in my shader so to look at how we compile a shader for tonights mission. See what has changed there. Do you know any major changes in that area :-)
Last edited by LdB on Tue Sep 05, 2017 3:00 pm, edited 1 time in total.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 18033
Joined: Sat Jul 30, 2011 7:41 pm

Re: Accelerated graphics

Tue Sep 05, 2017 2:41 pm

LdB wrote:
Tue Sep 05, 2017 7:46 am
At the moment I am trying to work out how I can future proof myself given we probably will have a new Pi coming with a VC5 (BCM7268) so I am looking at Eric Anholt's work closely. They already have a VC5 gallium driver done so the OpenGL path is fairly straight forward and they are saying the pipeline is OpenGL ES 3.1.
https://lists.freedesktop.org/archives/ ... 62087.html
The BCM7268 also has a MMU ^-^
https://anholt.github.io/twivc4/2017/08/28/twiv/
Holding breath whilst waiting for a PI4 is NOT recommended. This is years away. Not only that but the 7268 is entirely unsuited for a Pi4.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 18033
Joined: Sat Jul 30, 2011 7:41 pm

Re: Accelerated graphics

Tue Sep 05, 2017 2:45 pm

MOD: For some reason a link on a couple of posts here is kicking off malwarebytes. They are links to images from LdB, not sure why it thinks they are bad. I've edited out the links.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Tue Sep 05, 2017 3:03 pm

No worries James, they are probably too big or the stupid online image site pushing junk. Yeah I would guess a couple years on the Pi4 he hasn't even got it running yet :-)

Eric Anholt is really nice doing all his work opensource (I should send him a cheque) makes it much easier following his test code. I was able to drop the VCOS shim as he exposed the direct thread interface bits and how you hit them.

I still meant to chase you up if you happen to know what a dynamic resource is down there .. is that something to do with MMAL? It looks like you hook a DMA transfer so either sound or video is my guess or maybe the troublesome camera.

User avatar
Paeryn
Posts: 1673
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Accelerated graphics

Tue Sep 05, 2017 3:13 pm

OpenGLES has never had quads or polygons, not in 1, 2 or 3. Why are you looking at OpenGL specs when talking about what OpenGLES hardware is capable of? It doesn't matter when OpenGL deprecated or removed them, OpenGLES doesn't map 1:1 to any OpenGL spec, never has and probably never will.
She who travels light — forgot something.

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Tue Sep 05, 2017 3:28 pm

1.) All my OpenGL experience comes from Windows AKA OpenGL 3.3 so it's close enough (GLES2 is roughly OpenGL 3.1 core). So obviously you use what you are used to doing and what experience you have.

2.) VC4 pipeline is a little more advanced than just GLES2 it's got some interesting funky stuff. We are baremetal here we use whatever we can get out of the hardware. I will not follow some stupid old spec which maps to the minimum the VC4 is capable of.

3.) VC5 we already know is going to GLES3 which is the core of OpenGL 4.5 so if the VC4 has partials I might as well support what I can.

None of that is a slight on you Paeryn, you are a lot more technical than me I am just an old coder monkey.

Bottom line is however I don't give a rats about GLES2 spec I am simply looking what the VC4 can do in baremetal since Eric is exposing it all. I simply got caught out because I thought it had something it didn't, but my experience said it should be there. I suspect from what I am seeing in Eric's code there is something funky with ARB support as well and I haven't looked that up in GLES2 either. Quite possibly another difference between GLES2 and OpenGL 3.1.

Eric also has a DRM driver which hits the VC4 from linux which looks interesting. I don't know much about that yet either except it's hitting some interesting registers.
https://dri.freedesktop.org/docs/drm/gpu/vc4.html

So highly likely what I end up with will have bits of GLES, bits of OpenGL, bits of DRM and bits of MMAL :-)
Last edited by LdB on Tue Sep 05, 2017 4:02 pm, edited 2 times in total.

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Tue Sep 05, 2017 3:53 pm

Jamesh ignore my previous post I think I have found out what these dynamic things I keep tripping over are
https://anholt.livejournal.com/52972.html
With dma-buf fencing in the kernel, a "reservation object" generated by the dma-buf exporter tracks the fences of the various devices using the shared object, and then the device trivers get to look at that list and wait on on each others' fences when using it.

User avatar
Gavinmc42
Posts: 1517
Joined: Wed Aug 28, 2013 3:31 am

Re: Accelerated graphics

Wed Sep 06, 2017 3:29 am

2.) VC4 pipeline is a little more advanced than just GLES2 it's got some interesting funky stuff. We are baremetal here we use whatever we can get out of the hardware. I will not follow some stupid old spec which maps to the minimum the VC4 is capable of.

I agree, this is baremetal, not following old standards that are soon to be replaced anyway.
OpenGL on Pi I think Eric says needs some tweaking because the Pi is closer to OpenGLES in hardware.
OpenGL is not relevant for us baremetalers ;) unless we want to reinvent it ;)

LdB, Sorry for weird comments, sometimes forget your brain has not seen the same stuff as mine so you don't get the context, plus I don't explain the relevance. Been filling my head and odd things pop out, leakage of sorts :lol:

3.) VC5 we already know is going to GLES3 which is the core of OpenGL 4.5 so if the VC4 has partials I might as well support what I can.
Jamesh might say VC5 is not Pi4 and is not important, but for understanding the Videocore hardware any glimpse inside is useful.
If Pi4 is years away, good, I might understand the current Pi by then :oops:
Which settop boxes have VC5's in them? They could be fun to code on one day.

LdB, interesting code, going to take me a while to figure out.
pik33 has used a double sized framebuffer in Ultibo to stop tearing.
He normally uses assembler so it might be useful for you too.

I also thought there might have been quads in the VC but a search though the VC manual finds no mention, just triangle primitives.
Which when you think about it is all you need for 3D graphics.
I had found Eric's powerpoint last year, a lot more makes sense now
DRM.... Scariest code I've ever written
Yikes, sounds like fun. Would be interesting to compare this 2015 doc with a 2017 version.

For 3D graphics gurus like Eric this is day to day stuff, for old C coders like me it is all new.
Thanks for the img files too, it is nice to see working stuff before trying to figure out how to put together a C code toolset.

https://dri.freedesktop.org/docs/drm/gpu/vc4.html
In the VC4 driver, render command list generation is performed by the kernel instead of userspace
I understand this now, but baremetal is in the kernel space, well at least in Ultibo?
I think this is what Eric's code does so we do need to understand this DRM stuff.
We validate binner command lists to ensure that all accesses are within the bounds of the GEM objects referenced by the submitted job
Kind of important with a single memory map SOC, probably why the VC5 has a MMU.
To stop dumb things happening like the VC overwriting ARM code.

PL's code helped me understand the VG stuff but the GL and NV is still mostly a mystery.
Porting to Ultibo for me is harder because I am beginner Pascal coder. Chewing on a second elephant so to speak ;)
If you can get to step 6 in baremetal of those OpenGL lessons, it might become clearer :D
Step 4 is 3D GL, step 6 is NV?
Get those working and a basic baremetal 3D game engine could be made? Getting too far ahead?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Wed Sep 06, 2017 4:04 am

The texture loading is the weirdest thing I have seen in Eric code. If I am reading his code right you load the texture using OpenVG calls, share it using EGL and then display it using GL pipeline. I hope I made a mistake :-)

If you want me to convert the code to pascal I probably can except the emit_float. My pascal is rusty and I don't know how to do emit the 4 bytes of the raw float as bytes.

User avatar
Gavinmc42
Posts: 1517
Joined: Wed Aug 28, 2013 3:31 am

Re: Accelerated graphics

Wed Sep 06, 2017 5:13 am

Deciphering someones code is always fun, in Eric's case I imagine his stuff will look similar to the intel i945 code he has done.
Time for me to take a longer peek.

C to Pascal? Well your conversion will probably be better than mine ;)
But Free Pascal does allow inline assembler, so you could just convert the C to assembler.
As much as I "love" Pascal, assembler could then be used by anyone coding in any language?
My ARM assembler skills are even less :lol: It's on the list of things to learn :lol:
Lucky we do have a few expert assembler guys on the Ultibo forum.
Converting from assembler to ? language could then be up to the baremetaler.

Not sure if Python can use assembler? Micropython accelerated graphics etc.
Any scripting language could have accelerated graphics? Says someone who has never written a parser :oops:

I have been thinking about a simple 2D SVG engine for UI's, just not sure how the VG stuff can be used to make circles and rounded rectangles.
That's on the list too ;)
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Wed Sep 06, 2017 2:26 pm

You can turn the C into assembler code in an instant using online compiler explorer
So lets show you how
https://gcc.godbolt.org/#
Select arm-gcc 5.4.1 (6.3.0 is bugged)
add your ARM cpu details to compiler options
-O3 -mfpu=vfp -mfloat-abi=hard -march=armv6zk -mtune=arm1176jzf-s

cut and paste C code
so lets try

Code: Select all

#include <stdint.h>   // needed for uint8_t
struct __attribute__((__packed__, aligned(1))) EMITDATA {
	uint8_t byte1;
	uint8_t byte2;
	uint8_t byte3;
	uint8_t byte4;
};

void emit_float(uint8_t **list, float f) {
	struct EMITDATA* data = (struct EMITDATA*)&f;
	*((*list)++) = (*data).byte1;
	*((*list)++) = (*data).byte2;
	*((*list)++) = (*data).byte3;
	*((*list)++) = (*data).byte4;
}
produced ARM6 assembler code

Code: Select all

emit_float(unsigned char**, float):
  vmov r3, s0 @ int
  ldr r2, [r0]
  str lr, [sp, #-4]!
  add r1, r2, #1
  str r1, [r0]
  strb r3, [r2]
  ldr r2, [r0]
  mov ip, r3, lsr #8
  add lr, r2, #1
  str lr, [r0]
  strb ip, [r2]
  ldr r2, [r0]
  mov r1, r3, lsr #16
  add ip, r2, #1
  str ip, [r0]
  strb r1, [r2]
  ldr r2, [r0]
  mov r3, r3, lsr #24
  add r1, r2, #1
  str r1, [r0]
  strb r3, [r2]
  ldr pc, [sp], #4
So now you can do that all by yourself without needing me or anyone else :-)

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Wed Sep 06, 2017 3:07 pm

I also got an e-mail asking where I got all the pipeline numbers from, which are in the blob header file
https://github.com/raspberrypi/userland ... n_prod_4.h

They start at KHRN_HW_INSTR_HALT

That is the GLES blob numbers then Eric has extra ones in his test files that hits the GL pipeline. Some may be only VC5 I haven't verified his added ones yet.

The other file you want to grab a copy of is
https://github.com/raspberrypi/userland ... _int_ids.h

It lists all the function numbers for the VG, EGL and GLES calls.

Now my question anyone know or seen code blocks that deal with the shader compiler ? I have my shaders written I just need to find the compiler to pass the source into. I would prefer not to have to be firing up linux to make binary shaders all the time.

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Wed Sep 06, 2017 7:46 pm

Got sick of looking for shader compiler to do rotation properly so haxx moved the vertexes so I could look at framerate. It didn't tear the screen like I expected but that will probably come when I do it properly and it goes a lot faster.

https://github.com/LdB-ECM/Raspberry-Pi ... ES2_Rotate

Off to grab a model of something to get a better idea of speed and will hold buffers etc rather than rebuild each frame.

SD Card and FAT32 code should be up tomorrow as I need them for reading the 3D file I will use.

User avatar
Gavinmc42
Posts: 1517
Joined: Wed Aug 28, 2013 3:31 am

Re: Accelerated graphics

Thu Sep 07, 2017 2:03 am

So lets show you how
https://gcc.godbolt.org/#
Thanks LdB, very useful website, bookmarked ;)
Knew there was a reason to move to ARM64, it's much nicer and smaller :lol:

Hmm useful stuff is buried in the khronos source?
After you get the 3D stuff working you can port Vulkan ;)
I suspect we may see Vulkan on VC5 and maybe not on VC4.
Will settop boxes play games? Probably, if Vulkan can fit/run on them.

ARM64 multicore with NEON and VC5, first person shooters no problem?
Need Vulkan? 3-4years time - 20M Pi4's around?
Over 50M PS4's sold by 2017, will Pi's over take game consoles?
Need to get to 100M+ Pi's?

I am impressed with what Retropie can already do.
Baremetal games would be interesting, using tools like Ultibo it can be done in one smallish file.
Very easy to distribute one game file.
Just need some sort of menu to switch between the kernel.img's.
Maybe some sort of tiny OS, easy to do now.
Right now I will settle for hardware AA 2D UI's :lol:
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
Gavinmc42
Posts: 1517
Joined: Wed Aug 28, 2013 3:31 am

Re: Accelerated graphics

Thu Sep 07, 2017 3:31 am

https://anholt.github.io/twivc4/2017/09/05/twiv/

Did not see this, I am a few days behind, Vulkan on VC5 :D
Now we have to wait for Eric to come back from hols for more info.
Wonder where the VC5 source is hidden?

Forgot about this, did not notice that some of the bits in regs are now defined in vc4_regs.h
https://github.com/anholt/linux/tree/rp ... pu/drm/vc4

The HVS does not rate a mention in the VC manual, the Android source lists the Scaler regs but that's about it.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
Gavinmc42
Posts: 1517
Joined: Wed Aug 28, 2013 3:31 am

Re: Accelerated graphics

Thu Sep 07, 2017 12:22 pm

Found some Pascal OpenGL stuff
http://wiki.freepascal.org/OpenGL_Tutorial
https://github.com/Zaflis/nxpascal

Some of it makes sense now, display list sound familiar ;)
nxpascal demos work on Linux Mint..
The good thing with Free Pascal is it is usually portable, so a good chance it will run on Raspbian.
Seems to be a few
http://wiki.freepascal.org/Game_Engine

Wonder if a OpenGl wrapper can be made for baremetal GL stuff on Ultibo?
Think I might be getting ahead of myself, about 2 years ahead ;)
I suspect understanding OpenGL will help a little in understanding the VC v3d -GL NV VG stuff.

If any of these engine work in Raspbian then there is a good chance one day porting to Ultibo.
Some Delphi/FPC stuff just works when compiled on Ultibo :D
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Thu Sep 07, 2017 1:44 pm

Okay again let me teach you the fast way to evaluate whether something with OpenGL is worth looking at for the Pi. Just search for the word glBegin if it has it that word the code is totally unsuitable, both the nxPascal and the FreePascal link have that word and hence are pretty much useless.

I will give you a quick explaination when the GL hardware pipeline came into being and was agreed on by the vendors, the concept of glBegin and glEnd which is the old non pipeline GL died. In OpenGL terms that was at OpenGL 3.1. With GLES old version 1 to 1.1 is designed for non pipeline, while GLES2 is designed around the pipeline. EGL came to be the API that merged OpenGL and GLES and then Khronos added OpenVG (which had little uptake or market share). OpenVG got put on maintenance only in 2011 by Khronos (https://en.wikipedia.org/wiki/OpenVG) so you can ignore it going forward. The VC4 does have OpenVG so in the Pi case we can't just dismiss it like we would on other systems.

I did a quick search and I only found a couple of useful sites with modern OpenGL and Pascal.
https://www.freepascal-meets-sdl.net/ch ... rn-opengl/
This one was the best it's got great step by step but the description is all german (but I know what he is doing) :-)
http://mathias1000.bplaced.net/OpenGL_Tutorial/html/
It is in the Lazarus community so maybe see if someone is willing to translate it to English or you could try google translate (http://itools.com/tool/google-translate ... translator)

Try his sample codes on Ultibo :-)

So with all that in mind, if on a OpenGL website or GitHib the first thing to do is throw the word "glBegin" in a search and if you get a hit you can be pretty sure none of the information is useful.

User avatar
Gavinmc42
Posts: 1517
Joined: Wed Aug 28, 2013 3:31 am

Re: Accelerated graphics

Fri Sep 08, 2017 1:46 am

Thanks LdB,
I know even less about OpenGL than than the VC :oops:
The only reason for me to learn it would be to get familiar with how 3D graphics works.
Ie Vertex's, shaders, textures etc, as the VC4 seems to have hardware specific to these things it seems like I should know the basics.

I do use SDL stuff via pygame, mainly bitmapped images and SVG.
These are my immediate goals for baremetal on Ultibo.
JPEG, PNG, Bitmaps etc are already doable in software and tricks like memory and double buffering help speed things up.
Anti Aliasing can be done in software too, but it is slow, Peter's code shows a way to use the VC4 hardware control list for AA and VG.
To copy what I had done 5 years ago with Raspbian/Python/Pygame in Ultibo, all I need now is diagonal AA lines of variable width.
I could do it in software, AA code is only a dozen lines of code, but why not try to do it in hardware?

Trying to find what code is the real code buried under dependence and library layers is a pain.
Thanks for a quick way to determine usefulness, I really hate digging through lots of source files.
I had determined if it is a library they are mostly useless.
However kernel level stuff like Eric's DRM is closer to what is useful for baremetal.

Doing things baremetal means you can throw away/not use stuff you don't need.
Full OpenGL or EGL I don't need as they don't teach me how the hardware works and I'm a hardware guy who hates coding ;)

Hopefully before I really need to learn OpenGL Eric will have back ported Vulkan :D
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Fri Sep 08, 2017 4:30 am

Vulkan is just another driver API that sits on the same GPU. Vendors may choose to provide Vulkan or OpenGL/ GLES3 drivers and some will provide both. The drivers will be targetted at the O/S linux, Android, Windows etc and likely the sourcecode won't be released. As baremetal folk it is a pile of stuff we will never use and likely never understand.

On the current Pi's, you can't make a Vulkan driver it's missing a couple of key things on the GL pipeline hardware. The GL pipeline needs basically GLES3/OpenGL4.5 compliance for Vulkan. So on the Pi the whole Vulkan thing is kinda mute and it can't be back ported by anyone.

Anyhow have one spinning startrek enterprise ship. Just need to do some commenting and I will put it up as new sample.

LdB
Posts: 568
Joined: Wed Dec 07, 2016 2:29 pm

Re: Accelerated graphics

Mon Sep 11, 2017 4:50 pm

Okay got the SD Card + FAT32 reader code done for release
https://github.com/LdB-ECM/Raspberry-Pi ... r/SD_FAT32

Delay was me fighting with sub directories in FAT32 which I decided I wanted. It's strictly Read file only I will do the Write file at a later date for now I want to move on to displaying 3D mesh Models on the GL Pipeline.

So that done I should have a 3D Wavefront OBJ file viewer sample up very shortly.

Return to “Bare metal”

Who is online

Users browsing this forum: No registered users and 2 guests