The graphics controller (again)

On 2019 Apr 05 17:16:24, you wrote to All:

GD> Presumably the graphics controller fills up a frame buffer for display, GD> so, if one is not at a certain point using the controller to draw GD> something, could one write to the frame buffer directly?

formatting link

GD> Also, AIUI, the RPi communicates with the GPU via memory-based GD> message buffers, so the GPU must be running some form of background GD> kernel?

formatting link

GD> I assume that this must be the purpose of only one of the GPU GD> processors as running full motion video, say, in an MPEG stream, GD> must take quite a lot of computer time?

see above... today's GPUs are a lot more powerful than those of yesteryear...

GD> One part of the GPU must be simply concerned with taking the frame GD> buffer and emitting it as a composite video stream, so I wonder how GD> the aspect ratio is set up?

formatting link

GD> Sorry, a bit unstructured in the above, just musing; it's something GD> that I pick up after a few months before dropping it again; I'm GD> struggling to get to grips with the whole GPU thing.

see above but also understand that today's GPUs are basically multi-processor computers dedicated to doing video work... because they are multi-processor computers, they can also be used for other tasks at times... some examples would be doing calculations for protein modeling, weather analysis, digital coin generation, encryption, and more...

back in the day, i had a 12mhz 286 with two hard drives in it... i replaced the existing HD controller card with a caching controller card... the caching controller card had a 40mhz 286 chip on it with its own banks of memory on the card... this caching controller card was more powerful and had more memory than the machine it was installed in... i know this is not the same as with the GPUs but the moving from the old-school stuff to today's stuff is very similar...

in any case, the above links should help you understand more of what is going on and why...

--
)\/(ark 

Always Mount a Scratch Monkey 
 Click to see the full signature
Reply to
mark lewis
Loading thread data ...

Presumably the graphics controller fills up a frame buffer for display, so, if one is not at a certain point using the controller to draw something, could one write to the frame buffer directly?

Also, AIUI, the RPi communicates with the GPU via memory-based message buffers, so the GPU must be running some form of background kernel?

I assume that this must be the purpose of only one of the GPU processors as running full motion video, say, in an MPEG stream, must take quite a lot of computer time?

One part of the GPU must be simply concerned with taking the frame buffer and emitting it as a composite video stream, so I wonder how the aspect ratio is set up?

Sorry, a bit unstructured in the above, just musing; it's something that I pick up after a few months before dropping it again; I'm struggling to get to grips with the whole GPU thing.

Reply to
Gareth's was W7 now W10 Downstairs Computer

Wild ased guess? Nope

In hardware, perhaps.

Registers Id say. Probably somne dedicated hardware chomps through RAM and DACS it whilst the real GPU is in chage of whats IN the RAM

Trouble is its several steps removed from the API with linux specially on a Pi.

--
"The most difficult subjects can be explained to the most slow witted  
man if he has not formed any idea of them already; but the simplest  
 Click to see the full signature
Reply to
The Natural Philosopher

According to various official blogs, etc, yes. AIUI, the standard linux framebuffer api works properly on the Rpi.

Apparently, the GPU runs it's own microcode, which implements the "VideoCore" architecture. You can find detailed documentation on this architecture, and Broadcom's implementations for the RPi SoCs by searching the fine web.

Of course.

I'm not familiar with the internals of the VideoCore GPU, so I can't answer this question. Perhaps a thorough read-through of the VideoCore 3D Architecture Reference Guide would answer this question for you. See

formatting link
for details.

HTH

--
Lew Pitcher 
"In Skills, We Trust"
Reply to
Lew Pitcher

Have you looked at OMXPlayer?

formatting link

Omxplayer is a video player specifically made for the Raspberry Pi's GPU made by Edgar (gimli) Hucek from the XBMC/Kodi project. It relies on the OpenMAX hardware acceleration API, which is the Broadcom's VideoCore officially supported API for GPU video/audio processing.

Also here:

formatting link

--

Chris Elvidge, England
Reply to
Chris Elvidge

Display sizes are communicated to the GPU via the mailbox property interface, or the mailbox framebuffer interface:

formatting link
formatting link

I'm not sure if the GPU-side registers for changing output video timing (rather than just resolution) are exposed to the ARM.

Theo

Reply to
Theo

Interesting.

Thankyou.

Bookmarked

Reply to
Gareth's was W7 now W10 Downstairs Computer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.