> -----Original Message----- > From: amd-gfx [mailto:amd-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf > Of Emil Velikov > Sent: Thursday, July 06, 2017 5:21 AM > To: Li, Samuel > Cc: ML dri-devel; amd-gfx mailing list > Subject: Re: [PATCH libdrm 2/2] radeon: use asic id table to get chipset name > > On 5 July 2017 at 22:31, Li, Samuel <Samuel.Li@xxxxxxx> wrote: > >> - above all, as-is make check will fail > > Right, I did not check that. > > > >> - keeping the radeon API symmetrical to the amdgpu one would a good > idea > > The issue is Radeon does not have a struct similar to > amdgpu_device_handle. > Attach it to analogous primitive? Radeon libdrm is much different than amdgpu. There is no analog. > > > I think the current radeon API is simpler. Maybe a follow up change can > change amdgpu's API similar to radeon. > > > Exposing 3 entry points instead of 1 is _not_simpler. Also you cannot > change the existing API, since it also breaks the ABI. > Leading to crash/cause memory corruption when using existing binaries. > > >> - is adding yet another header really justified? > > radeon_asic_id.h? That is going to be used by ddx/mesa. > > > Where it's used is orthogonal. You don't need a separate _public_ > header for nearly every entry point ;-) Actually having a separate header makes sense for radeon. We currently expose a separate header for each set of functionality (one for buffer management, one for command submission, one for surface management). Adding the asic names to any of the existing ones doesn’t really make sense from a functional standpoint. Alex > > Thanks > Emil > _______________________________________________ > amd-gfx mailing list > amd-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
