The graphics controller (again)

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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.



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?

  https://en.wikipedia.org/wiki/Framebuffer

 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?

 https://en.wikipedia.org/wiki/Graphics_processing_unit

 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?

  https://en.wikipedia.org/wiki/Composite_video

 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
We've slightly trimmed the long signature. Click to see the full one.
Re: The graphics controller (again)
On 05/04/2019 17:16, Gareth's was W7 now W10 Downstairs Computer wrote:
Quoted text here. Click to load it

Wild ased guess? Nope

Quoted text here. Click to load it
In hardware, perhaps.

Quoted text here. Click to load it
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


Quoted text here. Click to load it

Quoted text here. Click to load it
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  
We've slightly trimmed the long signature. Click to see the full one.
Re: The graphics controller (again)
Gareth's was W7 now W10 Downstairs Computer wrote:

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.  

Quoted text here. Click to load it

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
  https://docs.broadcom.com/docs/12358545
for details.

Quoted text here. Click to load it

HTH
--  
Lew Pitcher
"In Skills, We Trust"

Re: The graphics controller (again)
On 05/04/2019 18:46, Lew Pitcher wrote:
Quoted text here. Click to load it

Have you looked at OMXPlayer? https://elinux.org/Omxplayer

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: https://github.com/popcornmix/omxplayer



--  

Chris Elvidge, England

Re: The graphics controller (again)
Quoted text here. Click to load it

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

https://github.com/raspberrypi/firmware/wiki/Mailbox-framebuffer-interface
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface

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

Theo

Re: The graphics controller (again)
On 07/04/2019 02:40, Theo wrote:
Quoted text here. Click to load it

Interesting.

Thankyou.

Bookmarked



Site Timeline