head 1.1; branch 1.1.1; access; symbols netbsd-11-0-RC5:1.1.1.3 netbsd-11-0-RC4:1.1.1.3 netbsd-11-0-RC3:1.1.1.3 netbsd-11-0-RC2:1.1.1.3 netbsd-11-0-RC1:1.1.1.3 netbsd-11:1.1.1.3.0.4 netbsd-11-base:1.1.1.3 netbsd-10-1-RELEASE:1.1.1.3 netbsd-9-4-RELEASE:1.1.1.1 netbsd-10-0-RELEASE:1.1.1.3 netbsd-10-0-RC6:1.1.1.3 netbsd-10-0-RC5:1.1.1.3 netbsd-10-0-RC4:1.1.1.3 netbsd-10-0-RC3:1.1.1.3 netbsd-10-0-RC2:1.1.1.3 netbsd-10-0-RC1:1.1.1.3 netbsd-10:1.1.1.3.0.2 netbsd-10-base:1.1.1.3 netbsd-9-3-RELEASE:1.1.1.1 mesa-21-3-7:1.1.1.3 netbsd-9-2-RELEASE:1.1.1.1 netbsd-9-1-RELEASE:1.1.1.1 netbsd-9-0-RELEASE:1.1.1.1 netbsd-9-0-RC2:1.1.1.1 netbsd-9-0-RC1:1.1.1.1 mesalib-19-1-7:1.1.1.2 netbsd-9:1.1.1.1.0.2 netbsd-9-base:1.1.1.1 mesa-18-3-6:1.1.1.1 mesa-18-3-4:1.1.1.1 xorg:1.1.1; locks; strict; comment @# @; 1.1 date 2019.03.10.03.42.39; author mrg; state Exp; branches 1.1.1.1; next ; commitid r12jo1Nf3ebQKLeB; 1.1.1.1 date 2019.03.10.03.42.39; author mrg; state Exp; branches; next 1.1.1.2; commitid r12jo1Nf3ebQKLeB; 1.1.1.2 date 2019.09.24.17.41.33; author maya; state Exp; branches; next 1.1.1.3; commitid KJXusGl8fi9AAhEB; 1.1.1.3 date 2022.05.09.01.23.37; author mrg; state Exp; branches; next ; commitid UEBs6hNk81DdQjDD; desc @@ 1.1 log @Initial revision @ text @This provides some background the design of the generated headers. We started out trying to generate bit fields but it evolved into the pack functions because of a few limitations: 1) Bit fields still generate terrible code today. Even with modern optimizing compilers you get multiple load+mask+store operations to the same dword in memory as you set individual bits. The compiler also has to generate code to mask out overflowing values (for example, if you assign 200 to a 2 bit field). Our driver never writes overflowing values so that's not needed. On the other hand, most compiler recognize that the template struct we use is a temporary variable and copy propagate the individual fields and do amazing constant folding. You should take a look at the code that gets generated when you compile in release mode with optimizations. 2) For some types we need to have overlapping bit fields. For example, some values are 64 byte aligned 32 bit offsets. The lower 5 bits of the offset are always zero, so the hw packs in a few misc bits in the lower 5 bits there. Other times a field can be either a u32 or a float. I tried to do this with overlapping anonymous unions and it became a big mess. Also, when using initializers, you can only initialize one union member so this just doesn't work with out approach. The pack functions on the other hand allows us a great deal of flexibility in how we combine things. In the case of overlapping fields (the u32 and float case), if we only set one of them in the pack function, the compiler will recognize that the other is initialized to 0 and optimize out the code to or it it. 3) Bit fields (and certainly overlapping anonymous unions of bit fields) aren't generally stable across compilers in how they're laid out and aligned. Our pack functions let us control exactly how things get packed, using only simple and unambiguous bitwise shifting and or'ing that works on any compiler. Once we have the pack function it allows us to hook in various transformations and validation as we go from template struct to dwords in memory: 1) Validation: As I said above, our driver isn't supposed to write overflowing values to the fields, but we've of course had lots of cases where we make mistakes and write overflowing values. With the pack function, we can actually assert on that and catch it at runtime. bitfields would just silently truncate. 2) Type conversions: some times it's just a matter of writing a float to a u32, but we also convert from bool to bits, from floats to fixed point integers. 3) Relocations: whenever we have a pointer from one buffer to another (for example a pointer from the meta data for a texture to the raw texture data), we have to tell the kernel about it so it can adjust the pointer to point to the final location. That means extra work we have to do extra work to record and annotate the dword location that holds the pointer. With bit fields, we'd have to call a function to do this, but with the pack function we generate code in the pack function to do this for us. That's a lot less error prone and less work. @ 1.1.1.1 log @from maya: Import mesa 18.3.4. Mesa 18.3.4 implements the OpenGL 4.5 API. Some drivers don't support all the features required in OpenGL 4.5. @ text @@ 1.1.1.2 log @Import mesa 19.1.7 New features in mesa 19.1.0: GL_ARB_parallel_shader_compile on all drivers. GL_EXT_gpu_shader4 on all GL 3.1 drivers. GL_EXT_shader_image_load_formatted on radeonsi. GL_EXT_texture_buffer_object on all GL 3.1 drivers. GL_EXT_texture_compression_s3tc_srgb on Gallium drivers and i965 (ES extension). GL_NV_compute_shader_derivatives on iris and i965. GL_KHR_parallel_shader_compile on all drivers. VK_EXT_buffer_device_address on Intel and RADV. VK_EXT_depth_clip_enable on Intel and RADV. VK_KHR_ycbcr_image_arrays on Intel. VK_EXT_inline_uniform_block on Intel and RADV. VK_EXT_external_memory_host on Intel. VK_EXT_host_query_reset on Intel and RADV. VK_KHR_surface_protected_capabilities on Intel and RADV. VK_EXT_pipeline_creation_feedback on Intel and RADV. VK_KHR_8bit_storage on RADV. VK_AMD_gpu_shader_int16 on RADV. VK_AMD_gpu_shader_half_float on RADV. VK_NV_compute_shader_derivatives on Intel. VK_KHR_shader_float16_int8 on Intel and RADV (RADV only supports int8). VK_KHR_shader_atomic_int64 on Intel. VK_EXT_descriptor_indexing on Intel. VK_KHR_shader_float16_int8 on Intel and RADV. GL_INTEL_conservative_rasterization on iris. VK_EXT_memory_budget on Intel. New features in mesa 19.0.0: GL_AMD_texture_texture4 on all GL 4.0 drivers. GL_EXT_shader_implicit_conversions on all drivers (ES extension). GL_EXT_texture_compression_bptc on all GL 4.0 drivers (ES extension). GL_EXT_texture_compression_rgtc on all GL 3.0 drivers (ES extension). GL_EXT_render_snorm on gallium drivers (ES extension). GL_EXT_texture_view on drivers supporting texture views (ES extension). GL_OES_texture_view on drivers supporting texture views (ES extension). GL_NV_shader_atomic_float on nvc0 (Fermi/Kepler only). Shader-based software implementations of GL_ARB_gpu_shader_fp64, GL_ARB_gpu_shader_int64, GL_ARB_vertex_attrib_64bit, and GL_ARB_shader_ballot on i965. VK_ANDROID_external_memory_android_hardware_buffer on Intel Fixed and re-exposed VK_EXT_pci_bus_info on Intel and RADV VK_EXT_scalar_block_layout on Intel and RADV VK_KHR_depth_stencil_resolve on Intel VK_KHR_draw_indirect_count on Intel VK_EXT_conditional_rendering on Intel VK_EXT_memory_budget on RADV Also, bug fixes. @ text @a60 18 Keeping genxml files tidy : In order to spot differences easily between generations, we keep genxml files sorted. You can trigger the sort by running : $ cd src/intel/genxml; ./sort_xml.sh gen_sort_tags.py is the script that sorts genxml files using with the following rules : 1) Tags are grouped in the following order , , , 2) tags are sorted through the value of their start attribute 3) Sort tags by dependency so that other scripts have everything properly ordered. @ 1.1.1.3 log @initial import of mesa 21.3.7 main changes since 19.1.7 include: - more support for Vulkan functions - better supported for newer radeonsi (both amdgpu and radeon backends) - various bug fixes in many drivers - many fixes and enhancements for intel drivers - some fixes for nvidia - OpenGL 4.6 for some drivers (intel, radeonsi) - intel Tigerlake and Rocketlake support - Vulkan 1.2 for some drivers - OpenGL 4.5, GLES 3.2, and more on llvmpipe - working Panfrost and Midgard drivers - fix warnings in radeonsi vs newer llvm @ text @d67 1 a67 1 $ cd src/intel/genxml; ./gen_sort_tags.py @