RE: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

[Li, Samuel]

> Another possibility is to simply put it in the toplevel directory.
I considered that too, but I prefer not to pollute the toplevel.

> It shouldn't take as much time as we've spent talking about it in this 
> thread. :}
Right, I meant you can go ahead if you would like to verify the names.

Sam

-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net] 
Sent: Thursday, June 01, 2017 11:06 PM
To: Li, Samuel <samuel...@amd.com>
Cc: amd-gfx@lists.freedesktop.org; Yuan, Xiaojie <xiaojie.y...@amd.com>
Subject: Re: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

On 01/06/17 11:27 PM, Li, Samuel wrote:
>> If amdgpu.ids living in the amdgpu directory prevents it from being used by 
>> libdrm_radeon (why?), let's put it in a new toplevel directory, e.g.
>> "data".
>>> README is also located in this directory.
>> Not the same thing. It documents things about the header files, and doesn't 
>> get installed anywhere.
> I think that is a personal preference.

If you're referring to naming the new directory "data", that's just a 
suggestion. Another possibility is to simply put it in the toplevel directory.

What I wrote about include/drm/README is easily verifiable fact.


>>> My preference is to pass the names only, not to audit from a coder's 
>>> view ...
>> That's not how we do things.
> It is a data file, not really a part of code.

There is nothing magic about it. It's subject to the review process just like 
any other file in the repository.

BTW, if you put the file outside of the amdgpu directory, you should send the 
patch to the dri-devel mailing list for review as well.


> It shall be your preference to decide how much time you would like to 
> spend in auditing the names :)

It shouldn't take as much time as we've spent talking about it in this thread. 
:}


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

[Michel Dänzer]

On 01/06/17 11:27 PM, Li, Samuel wrote:
>> If amdgpu.ids living in the amdgpu directory prevents it from being used by 
>> libdrm_radeon (why?), let's put it in a new toplevel directory, e.g.
>> "data".
>>> README is also located in this directory.
>> Not the same thing. It documents things about the header files, and doesn't 
>> get installed anywhere.
> I think that is a personal preference.

If you're referring to naming the new directory "data", that's just a
suggestion. Another possibility is to simply put it in the toplevel
directory.

What I wrote about include/drm/README is easily verifiable fact.


>>> My preference is to pass the names only, not to audit from a coder's 
>>> view ...
>> That's not how we do things.
> It is a data file, not really a part of code.

There is nothing magic about it. It's subject to the review process just
like any other file in the repository.

BTW, if you put the file outside of the amdgpu directory, you should
send the patch to the dri-devel mailing list for review as well.


> It shall be your preference to decide how much time you would like to
> spend in auditing the names :)

It shouldn't take as much time as we've spent talking about it in this
thread. :}


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

[Li, Samuel]

>If amdgpu.ids living in the amdgpu directory prevents it from being used by 
>libdrm_radeon (why?), let's put it in a new toplevel directory, e.g.
>"data".
>> README is also located in this directory.
> Not the same thing. It documents things about the header files, and doesn't 
> get installed anywhere.
I think that is a personal preference.

>> My preference is to pass the names only, not to audit from a coder's 
>> view ...
>That's not how we do things.
It is a data file, not really a part of code. It shall be your preference to 
decide how much time you would like to spend in auditing the names :)

Sam


-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net] 
Sent: Thursday, June 01, 2017 2:09 AM
To: Li, Samuel <samuel...@amd.com>
Cc: amd-gfx@lists.freedesktop.org; Yuan, Xiaojie <xiaojie.y...@amd.com>
Subject: Re: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

On 01/06/17 12:32 AM, Li, Samuel wrote:
>> From: Michel Dänzer [mailto:mic...@daenzer.net] On 31/05/17 07:31 AM, 
>> Li, Samuel wrote:
>>> From: Michel Dänzer [mailto:mic...@daenzer.net]
>>>> On 30/05/17 06:16 AM, Samuel Li wrote:
>>>>
>>>>> diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c new 
>>>>> file mode 100644 index 000..a43ca33
>>>>> --- /dev/null
>>>>> +++ b/amdgpu/amdgpu_asic_id.c
>>>>
>>>> [...]
>>>>
>>>>> +#include "xf86drm.h"
>>>>> +#include "amdgpu_drm.h"
>>>>
>>>> Should be
>>>>
>>>> #include 
>>>> #include 
>>>>
>>>> since these header files are not located in the same directory as 
>>>> amdgpu_asic_id.c.
>>>
>>>  [Sam] Actually, "" is used to include programmer-defined header 
>>> files, and <>  is used for files pre-designated by the compiler/IDE.
>> 
>> The only difference between the two is that #include "" first looks for the 
>> header file in the same directory where the file containing the #include 
>> directive (not necessarily the same as the original *.c file passed to the 
>> compiler/preprocessor) is located, after that it looks in the same paths in 
>> the same order as <>. So "" only really makes sense when the header file is 
>> in the same directory as the file including it.
> 
> [Sam] Please see here
> https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html

Thanks, I didn't know different search paths can apply with "" vs <>.
One learns something new every day. :) You can ignore the above then.


>>>>> diff --git a/include/drm/amdgpu.ids b/include/drm/amdgpu.ids new 
>>>>> file mode 100644 index 000..6d6b944
>>>>> --- /dev/null
>>>>> +++ b/include/drm/amdgpu.ids
>>>>
>>>> I think the path of this file in the repository should be 
>>>> amdgpu/amdgpu.ids rather than include/drm/amdgpu.ids.
>>>
>>> [Sam] The file is going to be shared with radeon.
>> 
>> We can cross that bridge when we get there. Meanwhile, it's not a header 
>> file and not installed under $prefix/include/, so it doesn't belong in 
>> include/.
> [Sam] I am planning to do it right after this.

If amdgpu.ids living in the amdgpu directory prevents it from being used by 
libdrm_radeon (why?), let's put it in a new toplevel directory, e.g.
"data".

> README is also located in this directory.

Not the same thing. It documents things about the header files, and doesn't get 
installed anywhere.


>>>>> @@ -0,0 +1,170 @@
>>>>> +# List of AMDGPU ID's
>>>>
>>>> This should say "IDs" instead of "ID's".
>>>>
>>>>
>>>>> +67FF,CF, 67FF:CF
>>>>> +67FF,EF, 67FF:EF
>>>>
>>>> There should be no such dummy entries in the file. If it's useful, 
>>>> amdgpu_get_marketing_name can return a dummy string based on the 
>>>> PCI ID and revision when there's no matching entry in the file.
>>>
>>> [Sam] I forwarded another thread to you.
>> 
>> Please make your argument explicitly, for the benefit of non-AMD readers of 
>> the amd-gfx list.
>> Anyway, I don't think that invalidates what I wrote, and Alex seems to 
>> agree. "67FF:CF" isn't a marketing name, so there should be no such entries 
>> in this file. It's not necessary anyway; assuming it's useful for 
>> amdgpu_get_marketing_name to return such "names", it

Re: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

[Michel Dänzer]

On 01/06/17 12:32 AM, Li, Samuel wrote:
>> From: Michel Dänzer [mailto:mic...@daenzer.net] 
>> On 31/05/17 07:31 AM, Li, Samuel wrote:
>>> From: Michel Dänzer [mailto:mic...@daenzer.net]
 On 30/05/17 06:16 AM, Samuel Li wrote:

> diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c new 
> file mode 100644 index 000..a43ca33
> --- /dev/null
> +++ b/amdgpu/amdgpu_asic_id.c

 [...]

> +#include "xf86drm.h"
> +#include "amdgpu_drm.h"

 Should be

 #include 
 #include 

 since these header files are not located in the same directory as 
 amdgpu_asic_id.c.
>>>
>>>  [Sam] Actually, "" is used to include programmer-defined header 
>>> files, and <>  is used for files pre-designated by the compiler/IDE.
>> 
>> The only difference between the two is that #include "" first looks for the 
>> header file in the same directory where the file containing the #include 
>> directive (not necessarily the same as the original *.c file passed to the 
>> compiler/preprocessor) is located, after that it looks in the same paths in 
>> the same order as <>. So "" only really makes sense when the header file is 
>> in the same directory as the file including it.
> 
> [Sam] Please see here
> https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html

Thanks, I didn't know different search paths can apply with "" vs <>.
One learns something new every day. :) You can ignore the above then.


> diff --git a/include/drm/amdgpu.ids b/include/drm/amdgpu.ids new 
> file mode 100644 index 000..6d6b944
> --- /dev/null
> +++ b/include/drm/amdgpu.ids

 I think the path of this file in the repository should be 
 amdgpu/amdgpu.ids rather than include/drm/amdgpu.ids.
>>>
>>> [Sam] The file is going to be shared with radeon.
>> 
>> We can cross that bridge when we get there. Meanwhile, it's not a header 
>> file and not installed under $prefix/include/, so it doesn't belong in 
>> include/.
> [Sam] I am planning to do it right after this.

If amdgpu.ids living in the amdgpu directory prevents it from being used
by libdrm_radeon (why?), let's put it in a new toplevel directory, e.g.
"data".

> README is also located in this directory.

Not the same thing. It documents things about the header files, and
doesn't get installed anywhere.


> @@ -0,0 +1,170 @@
> +# List of AMDGPU ID's

 This should say "IDs" instead of "ID's".


> +67FF,CF, 67FF:CF
> +67FF,EF, 67FF:EF

 There should be no such dummy entries in the file. If it's useful, 
 amdgpu_get_marketing_name can return a dummy string based on the PCI 
 ID and revision when there's no matching entry in the file.
>>>
>>> [Sam] I forwarded another thread to you.
>> 
>> Please make your argument explicitly, for the benefit of non-AMD readers of 
>> the amd-gfx list.
>> Anyway, I don't think that invalidates what I wrote, and Alex seems to 
>> agree. "67FF:CF" isn't a marketing name, so there should be no such entries 
>> in this file. It's not necessary anyway; assuming it's useful for 
>> amdgpu_get_marketing_name to return such "names", it can generate them on 
>> the fly when there is no matching entry in the file.
>> Ideally the issues above should be fixed in the original file we get from 
>> marketing (?), but meanwhile / failing that we should fix them up (and can 
>> easily with Git).
> 
> [Sam] Essentially marketing names are defined by Marketing. They are
> complicated as I can imagine. If you have questions regarding the
> names, the thread I forwarded has the contact you can use.
> IIRC, the hex format in marketing names has been used for very long
> time.

It's obviously not a "marketing name" but some kind of placeholder. We
don't need those in libdrm.

> My preference is to pass the names only, not to audit from a coder's
> view ...

That's not how we do things.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

[Michel Dänzer]

On 31/05/17 10:17 PM, Alex Deucher wrote:
> On Wed, May 31, 2017 at 1:15 AM, Michel Dänzer  wrote:
>> On 31/05/17 07:31 AM, Li, Samuel wrote:
>>> From: Michel Dänzer [mailto:mic...@daenzer.net]
 On 30/05/17 06:16 AM, Samuel Li wrote:

> +67FF,  CF, 67FF:CF
> +67FF,  EF, 67FF:EF

 There should be no such dummy entries in the file. If it's useful,
 amdgpu_get_marketing_name can return a dummy string based on the PCI ID
 and revision when there's no matching entry in the file.
>>>
>>> [Sam] I forwarded another thread to you.
>>
>> Please make your argument explicitly, for the benefit of non-AMD readers
>> of the amd-gfx list.
>>
>> Anyway, I don't think that invalidates what I wrote, and Alex seems to
>> agree. "67FF:CF" isn't a marketing name, so there should be no such
>> entries in this file. It's not necessary anyway; assuming it's useful
>> for amdgpu_get_marketing_name to return such "names", it can generate
>> them on the fly when there is no matching entry in the file.
>>
>> Ideally the issues above should be fixed in the original file we get
>> from marketing (?), but meanwhile / failing that we should fix them up
>> (and can easily with Git).
> 
> Thinking about this more, it probably doesn't matter that much.  By
> the time any of these cards with no marketing names get onto shelves,
> the names will be filled in.  That said, it does seem strange to have
> these dummy entries.

Right, by the time a product is released, we should have the final
marketing name and can just add that directly. I really don't see the
point of adding such dummy entries before that in the libdrm repository.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

[Li, Samuel]

Please see comments incline,

-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net] 
Sent: Wednesday, May 31, 2017 1:15 AM
To: Li, Samuel <samuel...@amd.com>
Cc: amd-gfx@lists.freedesktop.org; Yuan, Xiaojie <xiaojie.y...@amd.com>
Subject: Re: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

On 31/05/17 07:31 AM, Li, Samuel wrote:
> From: Michel Dänzer [mailto:mic...@daenzer.net]
>> On 30/05/17 06:16 AM, Samuel Li wrote:
>> 
>>> diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c new 
>>> file mode 100644 index 000..a43ca33
>>> --- /dev/null
>>> +++ b/amdgpu/amdgpu_asic_id.c
>> 
>> [...]
>> 
>>> +#include "xf86drm.h"
>>> +#include "amdgpu_drm.h"
>> 
>> Should be
>> 
>> #include 
>> #include 
>> 
>> since these header files are not located in the same directory as 
>> amdgpu_asic_id.c.
> 
>  [Sam] Actually, "" is used to include programmer-defined header 
> files, and <>  is used for files pre-designated by the compiler/IDE.

The only difference between the two is that #include "" first looks for the 
header file in the same directory where the file containing the #include 
directive (not necessarily the same as the original *.c file passed to the 
compiler/preprocessor) is located, after that it looks in the same paths in the 
same order as <>. So "" only really makes sense when the header file is in the 
same directory as the file including it.

[Sam] Please see here
https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html


>>> @@ -267,6 +274,11 @@ int amdgpu_device_initialize(int fd,
>>> amdgpu_vamgr_init(>vamgr_32, start, max,
>>>   dev->dev_info.virtual_address_alignment);
>>>  
>>> +   r = amdgpu_parse_asic_ids(>asic_ids);
>>> +   if (r)
>>> +   fprintf(stderr, "%s: Can not parse asic ids, 0x%x.",
>>> +   __func__, r);
>> 
>> "Cannot parse ASIC IDs"
>> 
>> Also, there should be curly braces around a multi-line statement.
> 
> [Sam] Can be done. However, it is still a single statement. Does it matter?

It might not be strictly required, but I think it does make the code clearer in 
this case.

[Sam] OK.

>>> diff --git a/include/drm/amdgpu.ids b/include/drm/amdgpu.ids new 
>>> file mode 100644 index 000..6d6b944
>>> --- /dev/null
>>> +++ b/include/drm/amdgpu.ids
>> 
>> I think the path of this file in the repository should be 
>> amdgpu/amdgpu.ids rather than include/drm/amdgpu.ids.
> 
> [Sam] The file is going to be shared with radeon.

We can cross that bridge when we get there. Meanwhile, it's not a header file 
and not installed under $prefix/include/, so it doesn't belong in include/.
[Sam] I am planning to do it right after this. README is also located in this 
directory.


>>> @@ -0,0 +1,170 @@
>>> +# List of AMDGPU ID's
>> 
>> This should say "IDs" instead of "ID's".
>> 
>> 
>>> +67FF,  CF, 67FF:CF
>>> +67FF,  EF, 67FF:EF
>> 
>> There should be no such dummy entries in the file. If it's useful, 
>> amdgpu_get_marketing_name can return a dummy string based on the PCI 
>> ID and revision when there's no matching entry in the file.
> 
> [Sam] I forwarded another thread to you.

Please make your argument explicitly, for the benefit of non-AMD readers of the 
amd-gfx list.
Anyway, I don't think that invalidates what I wrote, and Alex seems to agree. 
"67FF:CF" isn't a marketing name, so there should be no such entries in this 
file. It's not necessary anyway; assuming it's useful for 
amdgpu_get_marketing_name to return such "names", it can generate them on the 
fly when there is no matching entry in the file.
Ideally the issues above should be fixed in the original file we get from 
marketing (?), but meanwhile / failing that we should fix them up (and can 
easily with Git).

[Sam] Essentially marketing names are defined by Marketing. They are 
complicated as I can imagine. If you have questions regarding the names, the 
thread I forwarded has the contact you can use.
IIRC, the hex format in marketing names has been used for very long time. My 
preference is to pass the names only, not to audit from a coder's view ... that 
can make discussions much much more difficult.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

[Alex Deucher]

On Wed, May 31, 2017 at 1:15 AM, Michel Dänzer  wrote:
> On 31/05/17 07:31 AM, Li, Samuel wrote:
>> From: Michel Dänzer [mailto:mic...@daenzer.net]
>>> On 30/05/17 06:16 AM, Samuel Li wrote:
>>>
 diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c new
 file mode 100644 index 000..a43ca33
 --- /dev/null
 +++ b/amdgpu/amdgpu_asic_id.c
>>>
>>> [...]
>>>
 +#include "xf86drm.h"
 +#include "amdgpu_drm.h"
>>>
>>> Should be
>>>
>>> #include 
>>> #include 
>>>
>>> since these header files are not located in the same directory as
>>> amdgpu_asic_id.c.
>>
>>  [Sam] Actually, "" is used to include programmer-defined header files,
>> and <>  is used for files pre-designated by the compiler/IDE.
>
> The only difference between the two is that #include "" first looks for
> the header file in the same directory where the file containing the
> #include directive (not necessarily the same as the original *.c file
> passed to the compiler/preprocessor) is located, after that it looks in
> the same paths in the same order as <>. So "" only really makes sense
> when the header file is in the same directory as the file including it.
>
>
 @@ -267,6 +274,11 @@ int amdgpu_device_initialize(int fd,
 amdgpu_vamgr_init(>vamgr_32, start, max,
   dev->dev_info.virtual_address_alignment);

 +   r = amdgpu_parse_asic_ids(>asic_ids);
 +   if (r)
 +   fprintf(stderr, "%s: Can not parse asic ids, 0x%x.",
 +   __func__, r);
>>>
>>> "Cannot parse ASIC IDs"
>>>
>>> Also, there should be curly braces around a multi-line statement.
>>
>> [Sam] Can be done. However, it is still a single statement. Does it matter?
>
> It might not be strictly required, but I think it does make the code
> clearer in this case.
>
>
 diff --git a/include/drm/amdgpu.ids b/include/drm/amdgpu.ids
 new file mode 100644
 index 000..6d6b944
 --- /dev/null
 +++ b/include/drm/amdgpu.ids
>>>
>>> I think the path of this file in the repository should be
>>> amdgpu/amdgpu.ids rather than include/drm/amdgpu.ids.
>>
>> [Sam] The file is going to be shared with radeon.
>
> We can cross that bridge when we get there. Meanwhile, it's not a header
> file and not installed under $prefix/include/, so it doesn't belong in
> include/.
>
>
 @@ -0,0 +1,170 @@
 +# List of AMDGPU ID's
>>>
>>> This should say "IDs" instead of "ID's".
>>>
>>>
 +67FF,  CF, 67FF:CF
 +67FF,  EF, 67FF:EF
>>>
>>> There should be no such dummy entries in the file. If it's useful,
>>> amdgpu_get_marketing_name can return a dummy string based on the PCI ID
>>> and revision when there's no matching entry in the file.
>>
>> [Sam] I forwarded another thread to you.
>
> Please make your argument explicitly, for the benefit of non-AMD readers
> of the amd-gfx list.
>
> Anyway, I don't think that invalidates what I wrote, and Alex seems to
> agree. "67FF:CF" isn't a marketing name, so there should be no such
> entries in this file. It's not necessary anyway; assuming it's useful
> for amdgpu_get_marketing_name to return such "names", it can generate
> them on the fly when there is no matching entry in the file.
>
> Ideally the issues above should be fixed in the original file we get
> from marketing (?), but meanwhile / failing that we should fix them up
> (and can easily with Git).

Thinking about this more, it probably doesn't matter that much.  By
the time any of these cards with no marketing names get onto shelves,
the names will be filled in.  That said, it does seem strange to have
these dummy entries.

Alex
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

[Michel Dänzer]

On 31/05/17 07:31 AM, Li, Samuel wrote:
> From: Michel Dänzer [mailto:mic...@daenzer.net] 
>> On 30/05/17 06:16 AM, Samuel Li wrote:
>> 
>>> diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c new 
>>> file mode 100644 index 000..a43ca33
>>> --- /dev/null
>>> +++ b/amdgpu/amdgpu_asic_id.c
>> 
>> [...]
>> 
>>> +#include "xf86drm.h"
>>> +#include "amdgpu_drm.h"
>> 
>> Should be
>> 
>> #include 
>> #include 
>> 
>> since these header files are not located in the same directory as
>> amdgpu_asic_id.c.
> 
>  [Sam] Actually, "" is used to include programmer-defined header files,
> and <>  is used for files pre-designated by the compiler/IDE.

The only difference between the two is that #include "" first looks for
the header file in the same directory where the file containing the
#include directive (not necessarily the same as the original *.c file
passed to the compiler/preprocessor) is located, after that it looks in
the same paths in the same order as <>. So "" only really makes sense
when the header file is in the same directory as the file including it.


>>> @@ -267,6 +274,11 @@ int amdgpu_device_initialize(int fd,
>>> amdgpu_vamgr_init(>vamgr_32, start, max,
>>>   dev->dev_info.virtual_address_alignment);
>>>  
>>> +   r = amdgpu_parse_asic_ids(>asic_ids);
>>> +   if (r)
>>> +   fprintf(stderr, "%s: Can not parse asic ids, 0x%x.",
>>> +   __func__, r);
>> 
>> "Cannot parse ASIC IDs"
>> 
>> Also, there should be curly braces around a multi-line statement.
> 
> [Sam] Can be done. However, it is still a single statement. Does it matter?

It might not be strictly required, but I think it does make the code
clearer in this case.


>>> diff --git a/include/drm/amdgpu.ids b/include/drm/amdgpu.ids
>>> new file mode 100644
>>> index 000..6d6b944
>>> --- /dev/null
>>> +++ b/include/drm/amdgpu.ids
>> 
>> I think the path of this file in the repository should be
>> amdgpu/amdgpu.ids rather than include/drm/amdgpu.ids.
> 
> [Sam] The file is going to be shared with radeon.

We can cross that bridge when we get there. Meanwhile, it's not a header
file and not installed under $prefix/include/, so it doesn't belong in
include/.


>>> @@ -0,0 +1,170 @@
>>> +# List of AMDGPU ID's
>> 
>> This should say "IDs" instead of "ID's".
>> 
>> 
>>> +67FF,  CF, 67FF:CF
>>> +67FF,  EF, 67FF:EF
>> 
>> There should be no such dummy entries in the file. If it's useful,
>> amdgpu_get_marketing_name can return a dummy string based on the PCI ID
>> and revision when there's no matching entry in the file.
> 
> [Sam] I forwarded another thread to you.

Please make your argument explicitly, for the benefit of non-AMD readers
of the amd-gfx list.

Anyway, I don't think that invalidates what I wrote, and Alex seems to
agree. "67FF:CF" isn't a marketing name, so there should be no such
entries in this file. It's not necessary anyway; assuming it's useful
for amdgpu_get_marketing_name to return such "names", it can generate
them on the fly when there is no matching entry in the file.

Ideally the issues above should be fixed in the original file we get
from marketing (?), but meanwhile / failing that we should fix them up
(and can easily with Git).


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

[Li, Samuel]

Please see comments inline.

-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net] 
Sent: Monday, May 29, 2017 9:26 PM
To: Li, Samuel <samuel...@amd.com>
Cc: amd-gfx@lists.freedesktop.org; Yuan, Xiaojie <xiaojie.y...@amd.com>
Subject: Re: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

On 30/05/17 06:16 AM, Samuel Li wrote:
> From: Xiaojie Yuan <xiaojie.y...@amd.com>

I took a closer look and noticed some details (and some non-details about the 
amdgpu.ids file at the end).


> diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c new 
> file mode 100644 index 000..a43ca33
> --- /dev/null
> +++ b/amdgpu/amdgpu_asic_id.c

[...]

> +#include "xf86drm.h"
> +#include "amdgpu_drm.h"

Should be

#include 
#include 

since these header files are not located in the same directory as
amdgpu_asic_id.c.

 [Sam] Actually, "" is used to include programmer-defined header files, and <>  
is used for files pre-designated by the compiler/IDE.

> +static int parse_one_line(const char *line, struct amdgpu_asic_id *id)
> +{
> + char *buf, *saveptr;
> + char *s_did;
> + char *s_rid;
> + char *s_name;
> + char *endptr;
> + int r = 0;

This function could be simplified slightly by initializing r = -EINVAL
here and only setting it to 0 just before the out label.

[Sam]This is likely a personal preference. I am fine with current 
implementation which is clear.

> +int amdgpu_parse_asic_ids(struct amdgpu_asic_id **p_asic_id_table)
> +{

[...]

> + /* 1st valid line is file version */
> + while ((n = getline(, , fp)) != -1) {
> + /* trim trailing newline */
> + if (line[n - 1] == '\n')
> + line[n - 1] = '\0';

Should probably increment line_num here, otherwise the line number in
the error message below might be confusing.

[Sam]That is a good catch.

> + fprintf(stderr, "Invalid format: %s: line %d: %s\n",
> + AMDGPU_ASIC_ID_TABLE, line_num, line);

The second line should be indented to align with the opening parenthesis.

 [Sam] Can be done.

> + if (table_size >= table_max_size) {
> + /* double table size */
> + table_max_size *= 2;
> + asic_id_table = realloc(asic_id_table, table_max_size *
> + sizeof(struct amdgpu_asic_id));

Ditto.

[Sam] Can be done.

> + /* end of table */
> + id = asic_id_table + table_size;
> + memset(id, 0, sizeof(struct amdgpu_asic_id));

Might also want to realloc asic_id_table according to the final table
size, to avoid wasting memory.

[Sam] Good one.

> + if (r && asic_id_table) {
> + while (table_size--) {
> + id = asic_id_table + table_size;
> + if (id->marketing_name !=  NULL)
> + free(id->marketing_name);

free(NULL) works fine (and parse_one_line returns an error for
id->marketing_name == NULL anyway), so this can be simplified to

free(id->marketing_name);


[Sam] Can be done.

> @@ -140,6 +140,13 @@ static void 
> amdgpu_device_free_internal(amdgpu_device_handle dev)
>   close(dev->fd);
>   if ((dev->flink_fd >= 0) && (dev->fd != dev->flink_fd))
>   close(dev->flink_fd);
> + if (dev->asic_ids) {
> + for (id = dev->asic_ids; id->did; id++) {
> + if (id->marketing_name !=  NULL)
> + free(id->marketing_name);
> + }

Ditto, this can be simplified to

[Sam] Can be done.

for (id = dev->asic_ids; id->did; id++)
free(id->marketing_name);


> @@ -267,6 +274,11 @@ int amdgpu_device_initialize(int fd,
>   amdgpu_vamgr_init(>vamgr_32, start, max,
> dev->dev_info.virtual_address_alignment);
>  
> + r = amdgpu_parse_asic_ids(>asic_ids);
> + if (r)
> + fprintf(stderr, "%s: Can not parse asic ids, 0x%x.",
> + __func__, r);

"Cannot parse ASIC IDs"

Also, there should be curly braces around a multi-line statement.

[Sam] Can be done. However, it is still a single statement. Does it matter?

> @@ -297,13 +309,15 @@ int amdgpu_device_deinitialize(amdgpu_device_handle dev)
>  
>  const char *amdgpu_get_marketing_name(amdgpu_device_handle dev)
>  {
> - const struct amdgpu_asic_id_table_t *t = amdgpu_asic_id_table;
> + const struct amdgpu_asic_id *id;
> +
> + if (!dev->asic_ids)
> + return NULL;
>  
> - while (t->

Re: [PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

[Michel Dänzer]

On 30/05/17 06:16 AM, Samuel Li wrote:
> From: Xiaojie Yuan 

I took a closer look and noticed some details (and some non-details
about the amdgpu.ids file at the end).


> diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c
> new file mode 100644
> index 000..a43ca33
> --- /dev/null
> +++ b/amdgpu/amdgpu_asic_id.c

[...]

> +#include "xf86drm.h"
> +#include "amdgpu_drm.h"

Should be

#include 
#include 

since these header files are not located in the same directory as
amdgpu_asic_id.c.


> +static int parse_one_line(const char *line, struct amdgpu_asic_id *id)
> +{
> + char *buf, *saveptr;
> + char *s_did;
> + char *s_rid;
> + char *s_name;
> + char *endptr;
> + int r = 0;

This function could be simplified slightly by initializing r = -EINVAL
here and only setting it to 0 just before the out label.


> +int amdgpu_parse_asic_ids(struct amdgpu_asic_id **p_asic_id_table)
> +{

[...]

> + /* 1st valid line is file version */
> + while ((n = getline(, , fp)) != -1) {
> + /* trim trailing newline */
> + if (line[n - 1] == '\n')
> + line[n - 1] = '\0';

Should probably increment line_num here, otherwise the line number in
the error message below might be confusing.


> + fprintf(stderr, "Invalid format: %s: line %d: %s\n",
> + AMDGPU_ASIC_ID_TABLE, line_num, line);

The second line should be indented to align with the opening parenthesis.


> + if (table_size >= table_max_size) {
> + /* double table size */
> + table_max_size *= 2;
> + asic_id_table = realloc(asic_id_table, table_max_size *
> + sizeof(struct amdgpu_asic_id));

Ditto.


> + /* end of table */
> + id = asic_id_table + table_size;
> + memset(id, 0, sizeof(struct amdgpu_asic_id));

Might also want to realloc asic_id_table according to the final table
size, to avoid wasting memory.


> + if (r && asic_id_table) {
> + while (table_size--) {
> + id = asic_id_table + table_size;
> + if (id->marketing_name !=  NULL)
> + free(id->marketing_name);

free(NULL) works fine (and parse_one_line returns an error for
id->marketing_name == NULL anyway), so this can be simplified to

free(id->marketing_name);


> @@ -140,6 +140,13 @@ static void 
> amdgpu_device_free_internal(amdgpu_device_handle dev)
>   close(dev->fd);
>   if ((dev->flink_fd >= 0) && (dev->fd != dev->flink_fd))
>   close(dev->flink_fd);
> + if (dev->asic_ids) {
> + for (id = dev->asic_ids; id->did; id++) {
> + if (id->marketing_name !=  NULL)
> + free(id->marketing_name);
> + }

Ditto, this can be simplified to

for (id = dev->asic_ids; id->did; id++)
free(id->marketing_name);


> @@ -267,6 +274,11 @@ int amdgpu_device_initialize(int fd,
>   amdgpu_vamgr_init(>vamgr_32, start, max,
> dev->dev_info.virtual_address_alignment);
>  
> + r = amdgpu_parse_asic_ids(>asic_ids);
> + if (r)
> + fprintf(stderr, "%s: Can not parse asic ids, 0x%x.",
> + __func__, r);

"Cannot parse ASIC IDs"

Also, there should be curly braces around a multi-line statement.


> @@ -297,13 +309,15 @@ int amdgpu_device_deinitialize(amdgpu_device_handle dev)
>  
>  const char *amdgpu_get_marketing_name(amdgpu_device_handle dev)
>  {
> - const struct amdgpu_asic_id_table_t *t = amdgpu_asic_id_table;
> + const struct amdgpu_asic_id *id;
> +
> + if (!dev->asic_ids)
> + return NULL;
>  
> - while (t->did) {
> - if ((t->did == dev->info.asic_id) &&
> - (t->rid == dev->info.pci_rev_id))
> - return t->marketing_name;
> - t++;
> + for (id = dev->asic_ids; id->did; id++) {
> + if ((id->did == dev->info.asic_id) &&
> + (id->rid == dev->info.pci_rev_id))

The last line is indented incorrectly, should be 2 tabs and 4 spaces.


> diff --git a/include/drm/amdgpu.ids b/include/drm/amdgpu.ids
> new file mode 100644
> index 000..6d6b944
> --- /dev/null
> +++ b/include/drm/amdgpu.ids

I think the path of this file in the repository should be
amdgpu/amdgpu.ids rather than include/drm/amdgpu.ids.


> @@ -0,0 +1,170 @@
> +# List of AMDGPU ID's

This should say "IDs" instead of "ID's".


> +67FF,CF, 67FF:CF
> +67FF,EF, 67FF:EF

There should be no such dummy entries in the file. If it's useful,
amdgpu_get_marketing_name can return a dummy string based on the PCI ID
and revision when there's no matching entry in the file.


-- 
Earthling Michel Dänzer   |   http://www.amd.com

[PATCH libdrm v4 1/1] amdgpu: move asic id table to a separate file

[Samuel Li]

From: Xiaojie Yuan 

v2: fix an off by one error and leading white spaces
v3: use thread safe strtok_r(); initialize len before calling getline();
change printf() to drmMsg(); add initial amdgpu.ids
v4: integrate some recent internal changes, including format changes

Change-Id: I12216da14910f5e2b0970bc1fafc2a20b0ef1ba9
Reviewed-by: Junwei Zhang 
Signed-off-by: Samuel Li 
---
 Makefile.am  |   3 +
 amdgpu/Makefile.am   |   2 +
 amdgpu/Makefile.sources  |   2 +-
 amdgpu/amdgpu_asic_id.c  | 206 +++
 amdgpu/amdgpu_asic_id.h  | 165 -
 amdgpu/amdgpu_device.c   |  28 +--
 amdgpu/amdgpu_internal.h |  10 +++
 include/drm/amdgpu.ids   | 170 ++
 8 files changed, 413 insertions(+), 173 deletions(-)
 create mode 100644 amdgpu/amdgpu_asic_id.c
 delete mode 100644 amdgpu/amdgpu_asic_id.h
 create mode 100644 include/drm/amdgpu.ids

diff --git a/Makefile.am b/Makefile.am
index dfb8fcd..8de8f6c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -45,6 +45,9 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \
 
 pkgconfigdir = @pkgconfigdir@
 pkgconfig_DATA = libdrm.pc
+libdrmdatadir = $(datadir)/libdrm
+dist_libdrmdata_DATA = include/drm/amdgpu.ids
+export libdrmdatadir
 
 if HAVE_LIBKMS
 LIBKMS_SUBDIR = libkms
diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
index cf7bc1b..da71c1c 100644
--- a/amdgpu/Makefile.am
+++ b/amdgpu/Makefile.am
@@ -30,6 +30,8 @@ AM_CFLAGS = \
$(PTHREADSTUBS_CFLAGS) \
-I$(top_srcdir)/include/drm
 
+AM_CPPFLAGS = -DAMDGPU_ASIC_ID_TABLE=\"${libdrmdatadir}/amdgpu.ids\"
+
 libdrm_amdgpu_la_LTLIBRARIES = libdrm_amdgpu.la
 libdrm_amdgpu_ladir = $(libdir)
 libdrm_amdgpu_la_LDFLAGS = -version-number 1:0:0 -no-undefined
diff --git a/amdgpu/Makefile.sources b/amdgpu/Makefile.sources
index 487b9e0..bc3abaa 100644
--- a/amdgpu/Makefile.sources
+++ b/amdgpu/Makefile.sources
@@ -1,5 +1,5 @@
 LIBDRM_AMDGPU_FILES := \
-   amdgpu_asic_id.h \
+   amdgpu_asic_id.c \
amdgpu_bo.c \
amdgpu_cs.c \
amdgpu_device.c \
diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c
new file mode 100644
index 000..a43ca33
--- /dev/null
+++ b/amdgpu/amdgpu_asic_id.c
@@ -0,0 +1,206 @@
+/*
+ * Copyright © 2017 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xf86drm.h"
+#include "amdgpu_drm.h"
+#include "amdgpu_internal.h"
+
+static int parse_one_line(const char *line, struct amdgpu_asic_id *id)
+{
+   char *buf, *saveptr;
+   char *s_did;
+   char *s_rid;
+   char *s_name;
+   char *endptr;
+   int r = 0;
+
+   buf = strdup(line);
+   if (!buf)
+   return -ENOMEM;
+
+   /* ignore empty line and commented line */
+   if (strlen(line) == 0 || line[0] == '#') {
+   r = -EAGAIN;
+   goto out;
+   }
+
+   /* device id */
+   s_did = strtok_r(buf, ",", );
+   if (!s_did) {
+   r = -EINVAL;
+   goto out;
+   }
+
+   id->did = strtol(s_did, , 16);
+   if (*endptr) {
+   r = -EINVAL;
+   goto out;
+   }
+
+   /* revision id */
+   s_rid = strtok_r(NULL, ",", );
+   if (!s_rid) {
+   r = -EINVAL;
+   goto out;
+   }
+
+   id->rid = strtol(s_rid, , 16);
+   if (*endptr) {
+   r = -EINVAL;
+   goto out;
+   }
+
+   /* marketing name */
+   s_name = strtok_r(NULL, ",", );
+   if (!s_name) {
+   r = -EINVAL;
+   goto out;
+   }
+   /* trim leading whitespaces or tabs */
+   while (*s_name == ' ' || *s_name ==