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

Re: Accelerated graphics

Tue Sep 11, 2018 10:01 am

LizardLad_1 wrote:
Tue Sep 11, 2018 8:28 am
Thank you LdB. Sorry about my coding style I'm in an Australian high school where the only language the teacher knows is php and pascal. My teacher I think had a worse coding style than me all of his programs use global variables, nothing local. If you have any ideas of how I can improve and learn please feel free to share them.
There are plenty of books on it, it would be wrong of me to push one and I always have to program to my clients requirements so I don't have a favourite. However that said none of them would have you include every header in every file :-)
LizardLad_1 wrote:
Tue Sep 11, 2018 8:28 am
Another question, what would it involve to get a shader compiler working as I am interested in looking into that area?
The shader is nothing more than a block of VC4 assembler code. Usually there exists a shader compiler either on the GPU itself or even on the net that will take a standard shader file language like GLSL or SPIR-V and compile you the code. NVidia, Mali GPU's and a host of others do that. So usually it is as simple as learn the shader language put that into the shader compiler and then emit the code into a memory block (you now understand what emit means). The VC4 is awkward because the only shader that existed was in the bottom of MESA in the opengl drivers for linux. So usually there is actually nothing to learn beyond the standard shader language and I originally stopped because I did not feel like trying to redux a shader compiler out of the MESA code.

Recently that has changed Eric Anholt has been working away on developments on VC4 and VC5 driver and he has exposed a much cleaner interface to a shader compiler code. So it is on my todo list but you are welcome to take on the task :-)

There is stuff on the Pi userland repo which you can hook up into baremetal (as some have) but it is largely old opengl stuff that has known limitations and is out of date. The updated linux drivers open up far more possibilities and functions.

Whatever way you go including using the old userland libraries or linux itself you will need to learn a shader language. Personally I would suggest it be GLSL as that tends to be the most covered on the net but someone who plays in that area a lot like paeryn could probably help you out and may have a different view. You can largely learn the shader language online there are websites that let you write shader code and show the effect and there are binaries that will do the same on your PC, things like Shadertoy (tm).

LizardLad_1
Posts: 126
Joined: Sat Jan 13, 2018 12:29 am

Re: Accelerated graphics

Tue Sep 11, 2018 10:37 am

LdB wrote:

Code: Select all

uint32_t get_cpu_max_clock()
{
	uint32_t buffer[5] = { 0 };
	if (mailbox_tag_message(0, 5,
		0x00030004, 8, 8, 3, 0))
	{
		return buffer[4];
	}
	return 0;
}
Shouldn't it be

Code: Select all

uint32_t get_cpu_max_clock()
{
	uint32_t buffer[5] = { 0 };
	if (mailbox_tag_message(&(buffer[0]), 5,
		0x00030004, 8, 8, 3, 0))
	{
		return buffer[4];
	}
	return 0;
}

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

Re: Accelerated graphics

Tue Sep 11, 2018 11:48 am

You are correct, teach me for typing and not cut and pasting :-)

LizardLad_1
Posts: 126
Joined: Sat Jan 13, 2018 12:29 am

Re: Accelerated graphics

Wed Oct 10, 2018 8:40 pm

I have been trying the new GLES code and rendering it once the mmu is on and it worked. However there is a problem where if I render to the screen I cannot print to the screen and if I call another render the image is corrupted and I just get random green pixels everywhere. Is there a reason for this?

EDIT 1:
I can now call the render multiple times and print over the top of it. I can't modify the position of vertices once the mmu is on but I reckon that is an issue with the cache. I will just need to fix that.

Return to “Bare metal, Assembly language”