Hi folks,

This is the plain text versio= n of the previous email in case that was considered as spam.

--- Background ---

On the downstream Android, vendors = used to report GPU private memory allocations with debugfs nodes in their o= wn formats. However, debugfs nodes are getting deprecated in the next Andro= id release.

--- Proposal ---

We are taki= ng the chance to unify all the vendors to migrate their existing debugfs no= des into a standardized sysfs node structure. Then the platform is able to = do a bunch of useful things: memory profiling, system health coverage, fiel= d metrics, local shell dump, in-app api, etc.=C2=A0This proposal is better = served upstream as all GPU vendors can standardize a gpu memory structure a= nd reduce fragmentation across Android and Linux that clients can rely on.<= /div>

--- Detailed design ---

The sysfs node= =C2=A0structure=C2=A0looks like below:

/sys/devices/<ro.gfx.sy= sfs.0>/<pid>/<type_name>

e.g. "/sys/devices/m= ali0/gpu_mem/606/gl_buffer" and the gl_buffer is a node having the com= ma separated size values: "4096,81920,...,4096".

For the top level root, vendors can choose their own names based o= n the value of ro.gfx.sysfs.0 the vendors set. (1) For the multiple gpu dri= ver cases, we can use ro.gfx.sysfs.1, ro.gfx.sysfs.2 for the 2nd and 3rd KM= Ds. (2) It's also allowed to put some sub-dir for example "kgsl/gp= u_mem" or "mali0/gpu_mem" in the ro.gfx.sysfs.<channel>= ; property if the root name under /sys/devices/ is already created and used= for other purposes.

For the 2nd level "p= id", there are usually just a couple of them per snapshot, since we on= ly takes snapshot for the active ones.

For the= 3rd level "type_name", the type name will be one of the GPU memo= ry object types in lower case, and the value will be a comma separated sequ= ence of size values for all the allocations under that specific type.

We especially would like some comments on this part= . For the GPU memory object types, we defined 9 different types for Android= :

(1) UNKNOWN // not accounted for in any other category

(2)=C2=A0SHADER=C2=A0// shader binaries

(3)=C2=A0COMMAND=C2= =A0// allocations which have a lifetime similar to a VkCommandBuffer

<= div>(4)=C2=A0VULKAN=C2=A0// backing for VkDeviceMemory

(5)=C2=A0G= L_TEXTURE=C2=A0// GL Texture and RenderBuffer

(6)=C2=A0GL_BUFFER= =C2=A0// GL Buffer

(7)=C2=A0QUERY=C2=A0// backing for query

(8)=C2=A0DESCRIPTOR=C2=A0// allocations which have a lifetime similar = to a VkDescriptorSet

(9)=C2=A0TRANSIENT // random transient thing= s that the driver needs

We are wondering if those = type enumerations make sense to the upstream side as well, or maybe we just= deal with our own different type sets. Cuz on the Android side, we'll = just read those nodes named after the types we defined in the sysfs node st= ructure.

Looking forward to any concerns/comme= nts/suggestions!

Best regards,

Yiwei=

--000000000000ec4fd50595c06a50-- --===============1396659780== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============1396659780==--