Hi, I have several questions about Gallium. Some of them are about undocumented stuff, others are just little things from the top of my head. Please consider these as things I may do when time allows. 1) Flush flags Which PIPE_FLUSH_* flag is used to flush the command stream? There doesn't seem to be one and we need it for glFlush. What is PIPE_FLUSH_FRAME for? To my knowledge, Gallium doesn't know "frames". What a driver should do when it gets that flag? The same for PIPE_FLUSH_SWAPBUFFERS. I propose replacing the current flags with: - PIPE_FLUSH_COMMANDS // flush the command stream - PIPE_FLUSH_FRAMEBUFFER_CACHE // flush the write cache of the currently-set framebuffer - PIPE_FLUSH_TEXTURE_CACHE // invalidate the read cache of the currently-set textures 2) is_resource_referenced Now that the transfer functions are in pipe_context, is this hook really necessary? 3) fence_signalled and fence_finish Both of these functions take a driver-specific "flags" parameter (according to p_screen.h) and return an integer (probably driver-specific too), where zero means success. Could we either: - specify a valid set of arguments for "flags" and the return values, - or remove the "flags" parameters and change the return types to boolean? 4) geom_flags in is_format_supported Not only are these unused by any driver, they also are redundant. - PIPE_TEXTURE_GEOM_NON_SQUARE was obsoleted by PIPE_TEXTURE_RECT, which can be directly passed to is_format_supported. - PIPE_TEXTURE_GEOM_NON_POWER_OF_TWO was obsoleted by PIPE_CAP_NPOT_TEXTURES. Could the geom flags be removed? 5) Block compression formats naming Would anyone object to cleaning up the names of compression formats? There are (or will be) these formats: DXTn, RGTCn, LATCn, BPTCx. They have many things in common: - All of them have 4x4 pixel blocks. - One block is either 64 bits of 128 bits large. - RGTC and LATC are equal except for swizzling. - RGTC and LATC are based on DXTn encoding. I propose to copy the more consistent D3D11 naming and use the form PIPE_FORMAT_encoding_swizzle_type for all of them: PIPE_FORMAT_BC1_RGB_UNORM // DXT1 = BC1 PIPE_FORMAT_BC1_RGB_SRGB PIPE_FORMAT_BC1_RGBA_UNORM PIPE_FORMAT_BC1_RGBA_SRGB PIPE_FORMAT_BC2_RGBA_UNORM // DXT3 = BC2 PIPE_FORMAT_BC2_RGBA_SRGB PIPE_FORMAT_BC3_RGBA_UNORM // DXT5 = BC3 PIPE_FORMAT_BC3_RGBA_SRGB PIPE_FORMAT_BC4_R_UNORM // RGTC1 = BC4 PIPE_FORMAT_BC4_R_SNORM PIPE_FORMAT_BC4_L_UNORM // LATC1 = BC4 PIPE_FORMAT_BC4_L_SNORM PIPE_FORMAT_BC5_RG_UNORM // RGTC2 = D3D/3DC = BC5 PIPE_FORMAT_BC5_RG_SNORM PIPE_FORMAT_BC5_LA_UNORM // LATC2 = GL/3DC = BC5 PIPE_FORMAT_BC5_LA_SNORM PIPE_FORMAT_BC6_RGB_FLOAT // BPTC (BC6H) PIPE_FORMAT_BC6_RGB_UFLOAT PIPE_FORMAT_BC7_RGBA_UNORM // BPTC PIPE_FORMAT_BC7_RGBA_SRGB The layout for all of them would be UTIL_FORMAT_LAYOUT_BC. UFLOAT is a float without the sign bit. I guess UFLOAT should be used for R11G11B10_FLOAT and R9G9B9E5_FLOAT too. 6) Pixel buffer objects It woud be nice to have hardware-accelerated PBO copy in Gallium. Would resource_copy_region be a good candidate for this, where one of the arguments would be PIPE_BUFFER and the other one would be PIPE_TEXTURE_*, or am I missing something? 7) Stippling and smoothing Would anyone be against removing these two from the Gallium interface and fully implementing them in st/mesa? It's not like any of the radeon people wants to implement them in the hardware drivers, and the Draw module is not an option, because we still would like to have hardware-accelerated vertex shaders even with stippling and smoothing. Best regards Marek