<div class="gmail_quote">On Mon, Mar 7, 2011 at 11:38 AM, Keith Whitwell <<a href="mailto:keithw@vmware.com" target="_blank">keithw@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div>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 </div>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? </blockquote><div> 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. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div> > > 2) is_resource_referenced > > Now that the transfer functions are in pipe_context, is this hook > really > necessary? </div>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. </blockquote><div> Yes, drivers can do it internally very easily (and st/mesa doesn't even use is_resource_referenced now). </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div> > 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? </div>I'd prefer the latter. <div> > > 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? </div>This is OK with me too. <div><div></div><div> > 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. </div></div>Sounds good again, though this is more Jose's domain than mine. <div> > 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? </div>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. </blockquote><div> 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? </div> </div> Marek