Exposing GPU information for userspace processes
We are currently looking into exporting some information from the linux kernel to userspace about the GPU. This information is specific per board as the data can vary depending on the fuses burnt on the board.
Right now we are leaning towards adding sysfs properties to our existing nodes to share this information.
Before we write up the patches and update our userspace apps to check the new locations, we wanted to make sure there wasn't a more accepted/proper way to export information already.
Right now for instance we want to export a property to say how many pixel pipes there are. This could then be exported in something like:
/sys/bus/platform/drivers/gr3d/54180000.gr3d/num_pixel_pipes
Is this the best approach to take right now or is there another way we should export this and similar HW specific information?
Thanks,
Rhyland
Signature · 1 line
nvpublic
Quoted 11 lines · Rhyland Klein
We are currently looking into exporting some information from the linux kernel to userspace about the GPU. This information is specific per board as the data can vary depending on the fuses burnt on the board.
Right now we are leaning towards adding sysfs properties to our existing nodes to share this information.
Before we write up the patches and update our userspace apps to check the new locations, we wanted to make sure there wasn't a more accepted/proper way to export information already.
Quoted 7 lines
Right now for instance we want to export a property to say how many pixel pipes there are. This could then be exported in something like:
/sys/bus/platform/drivers/gr3d/54180000.gr3d/num_pixel_pipesIs this the best approach to take right now or is there another way we should export this and similar HW specific information?
All the x86 GPU drivers use gpu specific get param ioctls for this so far.
e.g. drivers/gpu/drm/radeon/radeon_kms.c:radeon_info_ioctl
Dave.
Dave.
Quoted 15 lines · Dave Airlie
Quoted 14 lines · Rhyland Klein
We are currently looking into exporting some information from the linux kernel to userspace about the GPU. This information is specific per board as the data can vary depending on the fuses burnt on the board.
Right now we are leaning towards adding sysfs properties to our existing nodes to share this information.
Before we write up the patches and update our userspace apps to check the new locations, we wanted to make sure there wasn't a more accepted/proper way to export information already.
Right now for instance we want to export a property to say how many pixel pipes there are. This could then be exported in something like:
Quoted 8 lines
Quoted 4 lines
/sys/bus/platform/drivers/gr3d/54180000.gr3d/num_pixel_pipesIs this the best approach to take right now or is there another way we should export this and similar HW specific information?
All the x86 GPU drivers use gpu specific get param ioctls for this so far.
e.g. drivers/gpu/drm/radeon/radeon_kms.c:radeon_info_ioctl
In drm/i915 we also expose a bunch of thing to sysfs, but everything that the userspace drivers need for operation is exposed through the getparam ioctl. We add sysfs interfaces on top if there's a legit reason for the user to script changes (e.g. gpu error state collection or tuning the frequency scaling and related read-only statistics).
-Daniel
Signature · 3 lines
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Quoted 23 lines · Daniel Vetter
Quoted 22 lines · Dave Airlie
Quoted 11 lines · Rhyland Klein
We are currently looking into exporting some information from the linux kernel to userspace about the GPU. This information is specific per board as the data can vary depending on the fuses burnt on the board.
Right now we are leaning towards adding sysfs properties to our existing nodes to share this information.
Before we write up the patches and update our userspace apps to check the new locations, we wanted to make sure there wasn't a more accepted/proper way to export information already.
Quoted 7 lines
Right now for instance we want to export a property to say how many pixel pipes there are. This could then be exported in something like:
/sys/bus/platform/drivers/gr3d/54180000.gr3d/num_pixel_pipesIs this the best approach to take right now or is there another way we should export this and similar HW specific information?
All the x86 GPU drivers use gpu specific get param ioctls for this so far.
Quoted 9 lines
Quoted 1 line
e.g. drivers/gpu/drm/radeon/radeon_kms.c:radeon_info_ioctl
In drm/i915 we also expose a bunch of thing to sysfs, but everything that the userspace drivers need for operation is exposed through the getparam ioctl. We add sysfs interfaces on top if there's a legit reason for the user to script changes (e.g. gpu error state collection or tuning the frequency scaling and related read-only statistics).
-Daniel
Thank you both for your helpful responses. I was considering an ioctl as another option, and it seems that is likely the best approach to take for this type of information.
Thanks,
-rhyland
Signature · 1 line
nvpublic
Quoted 15 lines · Dave Airlie
Quoted 14 lines · Rhyland Klein
We are currently looking into exporting some information from the linux kernel to userspace about the GPU. This information is specific per board as the data can vary depending on the fuses burnt on the board.
Right now we are leaning towards adding sysfs properties to our existing nodes to share this information.
Before we write up the patches and update our userspace apps to check the new locations, we wanted to make sure there wasn't a more accepted/proper way to export information already.
Right now for instance we want to export a property to say how many pixel pipes there are. This could then be exported in something like:
Quoted 8 lines
Quoted 4 lines
/sys/bus/platform/drivers/gr3d/54180000.gr3d/num_pixel_pipesIs this the best approach to take right now or is there another way we should export this and similar HW specific information?
All the x86 GPU drivers use gpu specific get param ioctls for this so far.
e.g. drivers/gpu/drm/radeon/radeon_kms.c:radeon_info_ioctl
If we want to add an IOCTL for it then we should take some care to craft it properly so we don't have to keep adding new ones because we forgot to provide half the information. Something like what radeon does looks like it's extensible enough for us not to have to worry too much.
Thierry