On Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote: > Handful of random things bugging me.
Bellow some answers for the things I know enough to comment. > 1) Team Fortress 2 (and probably other Source games, haven't really > checked) request some fairly large VBOs and indexbufs, beyond what I > can provide. Is there any good example code on how to use > translate/indices to slice up buffers for multiple render runs? Draw module has some code to break large VBOs. But I don't know how to set it up so that it does that without doing vertex processing though. Keith's might help you with that. > 3) Is there still interest in the translate helper I proposed a couple > weeks ago? It would take a list of "safe" formats, a list of VBO > elements, and a list of VBOs (corresponding), and return a list of VBO > elements and VBOs that only contain those "safe" formats. State > trackers would call a pipe_screen (or pipe_context?) method with just > the VBOs and elements, and it would fix them up without exposing the > list of safe formats. I've missed that mail. I've read the thread and I agree with Keith's reply. In summary, there are more than one way to skin this cat but your proposed helper seems an useful thing to have. > 5) How const is const for CSO? e.g. r300_state.c:498, we're not > copying pipe_framebuffer_state but just the pointer. It appears to > work, but is it actually safe? The const means the driver cannot change it. Not that it won't change. The long answer is depends on how the driver is implemented and commands batched. The next time the set_framebuffer_state is called the previous object may have been destroyed/modified, so if you have internal references to it they would cause segfault. But if by the time that happens you no longer have references to it -- e.g. you just have references to the BOs that hold the frambuffer storage -- then it would work fine. Short answer is -- it is better to just make a local copy. > Also, on the topic of framebuffers, is > it okay to refuse to render if no MRTs or Z buffer are present? Not really. At least not as it stands. If the hardware requires these then they'll need to be created internally by the pipe driver. We could add a caps for this but I see no point for it, since it's so easy to create a dummy framebuffer internally. > I think that's it for now. Sorry for all the questions, but I'm really > starting to get a good handle on the hardware and interface, and I'm > ready to start beating the classic driver in serious benchmarks; I > think that r300's probably the most mature driver alongside nv50 and > maybe nv40. That's great to hear. It has been really nice to see gallium driver development lately on so many different hardware, and with that seeing gallium interface more polished to abstract well more hardware. I think you've been doing a great work not only with the driver development, but also making the right questions, and documenting interfaces. Jose ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
