I can avoid modifying drm.h by doing this to drm_fourcc.h:
#ifdef _WIN32 #include <stdint.h> typedef uint64_t __u64; #else #include "drm.h" #endif
And this to amdgpu_drm.h:
#ifdef _WIN32 #include <stdint.h> typedef int32_t __s32; typedef uint32_t __u32; typedef uint64_t __u64; #else #include "drm.h" #endif
But now I'm touching two files under drm-uapi instead of one, and weirdly.
If we're trying to cut ties with the drm-uapi folder entirely, the stuff ac_surface.c need includes the AMD_FMT_MOD stuff in drm_fourcc.h, and AMDGPU_TILING_* under amdgpu_drm.h. Is there a better spot for these definitions?
Thanks, James
On Wed, Dec 2, 2020 at 10:06 AM Michel Dänzer michel@daenzer.net wrote:
On 2020-12-02 1:46 p.m., Daniel Vetter wrote:
On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer michel@daenzer.net
wrote:
On 2020-12-01 11:01 a.m., James Park wrote:
This will allow Mesa to port code to Windows more easily.
As discussed in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779
, including drm.h makes no sense when building for Windows.
Yeah I think it'd be cleanest if we can avoid this. If not I think the right fix would be to split out the actually needed parts from drm.h into a new header (still included by drm.h for backwards compat reasons) which mesa can use. Since it looks like the problematic parts are the legacy gunk, and not the new ioctl structures. Pulling out drm_render.h for all the render stuff and mabe drm_vblank.h for the vblank stuff (which would fit better in drm_mode.h but mistakes were made, oops).
If anything currently in drm.h is needed while building for Windows, it points to a broken abstraction somewhere in userspace. (Specifically, the Mesa Gallium/Vulkan winsys is supposed to abstract away platform details like these)
-- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer