Information resources

Information resources

[Phillip Susi]

I'm looking for resources I can read to learn more.  I mostly have some
basic questions that are probably in a FAQ or something, so if someone
could point me the right way I'd appreciate it.

Specifically some of the things I have been wondering are:

1)  It looks like the firmware is in the kernel tree in HEX file form.
Where can I find the source code?

2)  What is a "fence"?

Re: Information resources

[Jerome Glisse]

On Thu, Feb 24, 2011 at 2:50 PM, Phillip Susi <psusi@cfl.rr.com> wrote:
> I'm looking for resources I can read to learn more.  I mostly have some
> basic questions that are probably in a FAQ or something, so if someone
> could point me the right way I'd appreciate it.
>

dri.freedesktop.org has most informations we have (which is not a lot)
There is doc in kernel also about drm, high level.

> Specifically some of the things I have been wondering are:
>
> 1)  It looks like the firmware is in the kernel tree in HEX file form.
> Where can I find the source code?

We don't have source of firmware, only nouveau is reverse engineering
the nvidia one.

> 2)  What is a "fence"?

It's what it means, it tell the cpu when the gpu reached some point in
command stream or resource usage so we know we can free or move memory
that was previously in use. Or simply to know when gpu is done doing
somethings.

Cheers,
Jerome Glisse

Re: Information resources

[Phillip Susi]

On 2/24/2011 6:03 PM, Jerome Glisse wrote:
> We don't have source of firmware, only nouveau is reverse engineering
> the nvidia one.

Then where does the firmware come from?  I've been glancing at the AMD
documentation for the R600 and I'd like to figure out why the firmware
seems to be running in an infinite loop without ever halting, and
driving the temperature of my card over 80 C, but I need the original
assembly code for that.

>> 2)  What is a "fence"?
> 
> It's what it means, it tell the cpu when the gpu reached some point in
> command stream or resource usage so we know we can free or move memory
> that was previously in use. Or simply to know when gpu is done doing
> somethings.

So it is kind of like a barrier in the IO world?  You put a dozen
commands into the pipeline and then a fence, and when they all complete,
the fence gives you feedback so you know?

Re: Information resources

[Dave Airlie]

On Fri, 2011-02-25 at 09:38 -0500, Phillip Susi wrote:
> On 2/24/2011 6:03 PM, Jerome Glisse wrote:
> > We don't have source of firmware, only nouveau is reverse engineering
> > the nvidia one.
> 
> Then where does the firmware come from?  I've been glancing at the AMD
> documentation for the R600 and I'd like to figure out why the firmware
> seems to be running in an infinite loop without ever halting, and
> driving the temperature of my card over 80 C, but I need the original
> assembly code for that.

How do you know its running in an infinite loop?

the firmware comes in blobs from AMD.

> 
> >> 2)  What is a "fence"?
> > 
> > It's what it means, it tell the cpu when the gpu reached some point in
> > command stream or resource usage so we know we can free or move memory
> > that was previously in use. Or simply to know when gpu is done doing
> > somethings.
> 
> So it is kind of like a barrier in the IO world?  You put a dozen
> commands into the pipeline and then a fence, and when they all complete,
> the fence gives you feedback so you know?

Pretty much yes.

Dave.

Re: Information resources

[Garry Hurley Jr.]

The infinite loop you mentioned sounds like it could be several things. Polling could explain an infinite loop - "while true {checkForUpdates();}". Such code was common enough in some videi games, too. I think that mechanism has been replaced by scheduled and periodic checks in most cases, but you could have some old code running somewhere. 

Sent from my iPhone

On Feb 25, 2011, at 9:38 AM, Phillip Susi <psusi@cfl.rr.com> wrote:

> On 2/24/2011 6:03 PM, Jerome Glisse wrote:
>> We don't have source of firmware, only nouveau is reverse engineering
>> the nvidia one.
> 
> Then where does the firmware come from?  I've been glancing at the AMD
> documentation for the R600 and I'd like to figure out why the firmware
> seems to be running in an infinite loop without ever halting, and
> driving the temperature of my card over 80 C, but I need the original
> assembly code for that.
> 
>>> 2)  What is a "fence"?
>> 
>> It's what it means, it tell the cpu when the gpu reached some point in
>> command stream or resource usage so we know we can free or move memory
>> that was previously in use. Or simply to know when gpu is done doing
>> somethings.
> 
> So it is kind of like a barrier in the IO world?  You put a dozen
> commands into the pipeline and then a fence, and when they all complete,
> the fence gives you feedback so you know?
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Information resources

[Alex Deucher]

On Fri, Feb 25, 2011 at 9:38 AM, Phillip Susi <psusi@cfl.rr.com> wrote:
> On 2/24/2011 6:03 PM, Jerome Glisse wrote:
>> We don't have source of firmware, only nouveau is reverse engineering
>> the nvidia one.
>
> Then where does the firmware come from?  I've been glancing at the AMD
> documentation for the R600 and I'd like to figure out why the firmware
> seems to be running in an infinite loop without ever halting, and
> driving the temperature of my card over 80 C, but I need the original
> assembly code for that.

The CP firmware has nothing to do with the temperature.  The CP
firmware is just a packet parser for reading in command buffers and
programming the register backbone.  Just alike a CPU, the GPU runs at
whatever speed it's clock is set to.  You can manually force lower
power states using sysfs.  See the power management section of this
page:
http://wiki.x.org/wiki/RadeonFeature

Alex

>
>>> 2)  What is a "fence"?
>>
>> It's what it means, it tell the cpu when the gpu reached some point in
>> command stream or resource usage so we know we can free or move memory
>> that was previously in use. Or simply to know when gpu is done doing
>> somethings.
>
> So it is kind of like a barrier in the IO world?  You put a dozen
> commands into the pipeline and then a fence, and when they all complete,
> the fence gives you feedback so you know?
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Re: Information resources

[Phillip Susi]

On 2/25/2011 3:03 PM, Dave Airlie wrote:
> How do you know its running in an infinite loop?

Because the gpu temperature is rising to over 80 C, so it is busy doing
something.  And this is booting with init=/bin/bash, so NOTHING is
running that could be keeping it busy.

I had been under the impression that since ati/amd started releasing
documentation a few years ago that the mesa driver had managed to
implement its own firmware.  I sounds more like it has ripped the
firmware out of the proprietary driver and reverse engineered the interface?

Re: Information resources

[Dave Airlie]

On Fri, 2011-02-25 at 15:42 -0500, Phillip Susi wrote:
> On 2/25/2011 3:03 PM, Dave Airlie wrote:
> > How do you know its running in an infinite loop?
> 
> Because the gpu temperature is rising to over 80 C, so it is busy doing
> something.  And this is booting with init=/bin/bash, so NOTHING is
> running that could be keeping it busy.

So you made an assumpution you knew how graphics cards worked and
derived a theory, unfortunately the assumption was wrong.

a GPU doing nothing still runs at a high clock speed, clocking the
memory bus for the video RAM at full tilt. We don't have reliably
dynamic power management yet so at the moment manual clock switching is
all we have.

Even if the CP was running in a tight loop it consumes no power compared
to the memory interfaces.

> 
> I had been under the impression that since ati/amd started releasing
> documentation a few years ago that the mesa driver had managed to
> implement its own firmware.  I sounds more like it has ripped the
> firmware out of the proprietary driver and reverse engineered the interface?

Yes and no. AMD supplied firmware from their driver with the interfaces
documented like they have done since r100. You could write your own
microcode after you RE and write an assembler for the CP core, but so
far nobody has done this and we have a lot of other areas to improve
before most of the developers would care.

Dave.

Re: Information resources

[Garry Hurley]

[-- Attachment #1.1: Type: text/plain, Size: 2066 bytes --]

I am going to have to get caught up on the development chain.  I dropped off
for a while while I pursued my MS degree and concentrated on paying the
bills, but I am going to have to get back into the thick of coding.  I am
going through withdrawal. Management courses and systems administration
tasks are enough to drive any good developer to blog on facebook.

On Fri, Feb 25, 2011 at 3:56 PM, Dave Airlie <airlied@redhat.com> wrote:

> On Fri, 2011-02-25 at 15:42 -0500, Phillip Susi wrote:
> > On 2/25/2011 3:03 PM, Dave Airlie wrote:
> > > How do you know its running in an infinite loop?
> >
> > Because the gpu temperature is rising to over 80 C, so it is busy doing
> > something.  And this is booting with init=/bin/bash, so NOTHING is
> > running that could be keeping it busy.
>
> So you made an assumpution you knew how graphics cards worked and
> derived a theory, unfortunately the assumption was wrong.
>
> a GPU doing nothing still runs at a high clock speed, clocking the
> memory bus for the video RAM at full tilt. We don't have reliably
> dynamic power management yet so at the moment manual clock switching is
> all we have.
>
> Even if the CP was running in a tight loop it consumes no power compared
> to the memory interfaces.
>
> >
> > I had been under the impression that since ati/amd started releasing
> > documentation a few years ago that the mesa driver had managed to
> > implement its own firmware.  I sounds more like it has ripped the
> > firmware out of the proprietary driver and reverse engineered the
> interface?
>
> Yes and no. AMD supplied firmware from their driver with the interfaces
> documented like they have done since r100. You could write your own
> microcode after you RE and write an assembler for the CP core, but so
> far nobody has done this and we have a lot of other areas to improve
> before most of the developers would care.
>
> Dave.
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[-- Attachment #1.2: Type: text/html, Size: 2736 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Information resources

[Phillip Susi]

On 02/25/2011 03:38 PM, Alex Deucher wrote:
> The CP firmware has nothing to do with the temperature.  The CP
> firmware is just a packet parser for reading in command buffers and
> programming the register backbone.  Just alike a CPU, the GPU runs at
> whatever speed it's clock is set to.  You can manually force lower
> power states using sysfs.  See the power management section of this
> page:
> http://wiki.x.org/wiki/RadeonFeature

I have tried writing low to power_profile and it seems to make little to 
no difference.  A cpu executing a tight loop busy waiting for something 
to do wastes a lot more power than one that has executed a HLT 
instruction, or used even better stop states to gate off clocks that are 
not needed.  It seems to me that when there is nothing for the GPU to 
do, it also should stop executing instructions and gate off any unneeded 
clocks.

Re: Information resources

[Alex Deucher]

On Fri, Feb 25, 2011 at 6:03 PM, Phillip Susi <psusi@cfl.rr.com> wrote:
> On 02/25/2011 03:38 PM, Alex Deucher wrote:
>>
>> The CP firmware has nothing to do with the temperature.  The CP
>> firmware is just a packet parser for reading in command buffers and
>> programming the register backbone.  Just alike a CPU, the GPU runs at
>> whatever speed it's clock is set to.  You can manually force lower
>> power states using sysfs.  See the power management section of this
>> page:
>> http://wiki.x.org/wiki/RadeonFeature
>
> I have tried writing low to power_profile and it seems to make little to no
> difference.  A cpu executing a tight loop busy waiting for something to do
> wastes a lot more power than one that has executed a HLT instruction, or
> used even better stop states to gate off clocks that are not needed.  It
> seems to me that when there is nothing for the GPU to do, it also should
> stop executing instructions and gate off any unneeded clocks.
>

It only executes instructions when you tell it to; it's not running
constantly.  At the moment clock gating support is not implemented on
newer asics.

Alex

Re: Information resources

[Phillip Susi]

On 02/25/2011 03:56 PM, Dave Airlie wrote:
> So you made an assumpution you knew how graphics cards worked and
> derived a theory, unfortunately the assumption was wrong.

How so?  After studying the R600 documentation I found, it sounds like 
whatever microcode is in that firmware image is constantly running, 
trying to process input from the ring buffer.  Perhaps you could point 
me to more documentation to read, as the one I found seemed to be geared 
more towards GPGPU programming.

> a GPU doing nothing still runs at a high clock speed, clocking the
> memory bus for the video RAM at full tilt. We don't have reliably
> dynamic power management yet so at the moment manual clock switching is
> all we have.

If it were actually doing nothing ( as opposed to busy waiting ), then 
it wouldn't be hammering the memory bus full tilt.

> Even if the CP was running in a tight loop it consumes no power compared
> to the memory interfaces.

How so?  The memory interface feeds requested data to the CP, so if it 
isn't running...

> Yes and no. AMD supplied firmware from their driver with the interfaces
> documented like they have done since r100. You could write your own
> microcode after you RE and write an assembler for the CP core, but so
> far nobody has done this and we have a lot of other areas to improve
> before most of the developers would care.

Could you point me to this documentation?

Re: Information resources

[Alex Deucher]

On Fri, Feb 25, 2011 at 6:09 PM, Phillip Susi <psusi@cfl.rr.com> wrote:
> On 02/25/2011 03:56 PM, Dave Airlie wrote:
>>
>> So you made an assumpution you knew how graphics cards worked and
>> derived a theory, unfortunately the assumption was wrong.
>
> How so?  After studying the R600 documentation I found, it sounds like
> whatever microcode is in that firmware image is constantly running, trying
> to process input from the ring buffer.  Perhaps you could point me to more
> documentation to read, as the one I found seemed to be geared more towards
> GPGPU programming.

The CP only starts fetching and processing commands when the read and
write pointers are different.  Once they are the same, the CP stops
executing.  See Chapter 5 of this doc:
http://www.x.org/docs/AMD/R5xx_Acceleration_v1.5.pdf
It's for r5xx hardware, but the CP works the same way on all radeons.

>
>> a GPU doing nothing still runs at a high clock speed, clocking the
>> memory bus for the video RAM at full tilt. We don't have reliably
>> dynamic power management yet so at the moment manual clock switching is
>> all we have.
>
> If it were actually doing nothing ( as opposed to busy waiting ), then it
> wouldn't be hammering the memory bus full tilt.

The memory clock is still running at whatever clock it's set to unless
you manually change it.  Things are like displays are constantly being
fed from vram.

>
>> Even if the CP was running in a tight loop it consumes no power compared
>> to the memory interfaces.
>
> How so?  The memory interface feeds requested data to the CP, so if it isn't
> running...
>
>> Yes and no. AMD supplied firmware from their driver with the interfaces
>> documented like they have done since r100. You could write your own
>> microcode after you RE and write an assembler for the CP core, but so
>> far nobody has done this and we have a lot of other areas to improve
>> before most of the developers would care.
>
> Could you point me to this documentation?

See chapter 6 of this doc for pre6xx asics:
http://www.x.org/docs/AMD/R5xx_Acceleration_v1.5.pdf
and this chapter 5 of this doc for 6xx+ asics:
http://www.x.org/docs/AMD/R6xx_R7xx_3D.pdf

Alex

>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Re: Information resources

[Phillip Susi]

On 02/25/2011 06:19 PM, Alex Deucher wrote:
> The memory clock is still running at whatever clock it's set to unless
> you manually change it.  Things are like displays are constantly being
> fed from vram.

Sure, the master clock is still running, but the dac only reads from the 
frame buffer so fast.  Most of the clocks should be idle ( no read or 
write line asserted, no addressing, etc ) so it shouldn't be dissipating 
THAT much heat should it?

Re: Information resources

[Alex Deucher]

On Fri, Feb 25, 2011 at 6:30 PM, Phillip Susi <psusi@cfl.rr.com> wrote:
> On 02/25/2011 06:19 PM, Alex Deucher wrote:
>>
>> The memory clock is still running at whatever clock it's set to unless
>> you manually change it.  Things are like displays are constantly being
>> fed from vram.
>
> Sure, the master clock is still running, but the dac only reads from the
> frame buffer so fast.  Most of the clocks should be idle ( no read or write
> line asserted, no addressing, etc ) so it shouldn't be dissipating THAT much
> heat should it?
>

The clocks branches are all on and as I said before, clock gating
isn't implemented yet on newer asics.

Alex