On Mon, Mar 7, 2011 at 11:38 AM, Keith Whitwell <kei...@vmware.com> wrote:
> On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote: > > > > 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 > > I'm not sure if the flags add any value & have been the source of > bugs/confusion in the past. > > How about just removing the parameter? > I was thinking the flush cache flags could be used to implement GL_NV_texture_barrier (or we could add another entrypoint for it). I don't know of any other use, though. > > > > 2) is_resource_referenced > > > > Now that the transfer functions are in pipe_context, is this hook > > really > > necessary? > > Good question. I'd like to see those functions go away as they are > round-trips baked into the interface which is a pain if you try and > remote this stuff. > > I guess you'd still need to catch the write-after-read case within a > single context and turn that into a flush. > > I think others (Jose in particular) should comment, but I suspect that > individual drivers could now do this internally & not need to expose the > interface in gallium. > Yes, drivers can do it internally very easily (and st/mesa doesn't even use is_resource_referenced now). > > 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? > > I'd prefer the latter. > > > > > 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? > > This is OK with me too. > > > 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. > > Sounds good again, though this is more Jose's domain than mine. > > > 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? > > Do you have a more concrete proposal? > > For me, it's always been a bit difficult to pin down what a PBO really > should map to either in hardware or gallium's abstraction of hardware. > Sometimes it's a long lived entity (eg. pipe_buffer), other times it's > just a transient object used for uploads - dma memory from a pool or a > pipe_transfer in gallium. > > But if there's a sensible addition to gallium that improves the > situation, I'm all for it. > A PBO to me is just a way to copy data between a buffer and a texture. Two cases may arise: - The copy can be implemented using util_copy_rect (basically it's a memcpy with strides), in this case, resource_copy_region could be used to let drivers do the copy in hardware. - The copy cannot be implemented using util_copy_rect, in this case, the state tracker would use the current software implementation of PBOs. Again, another two cases may arise inside resource_copy_region: - If the strides are well aligned, the copy can done in hardware. (what is "well aligned" is hardware-specific) - If they are not, a util function similar to util_resource_copy_region could be used as a fallback. But then resource_copy_region needs to know the stride for the buffer being copied. New entrypoint maybe? Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
