On Sat, Jan 30, 2010 at 5:13 AM, Roland Scheidegger <srol...@vmware.com> wrote: > On 30.01.2010 13:06, Corbin Simpson wrote: >> Handful of random things bugging me. > >> 2) progs/tests/drawbuffers and progs/tests/drawbuffers2, and possibly >> others, segfault with both softpipe and the HW driver at >> sl_pp_version.c:45. I think there's some codegen going on there? At >> any rate, if anybody has any hints on how to solve it, that'd be nice. > Works for me (with softpipe).
Curses, looks like I'll have to dig in myself. Thanks though. >> >> 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in >> the fragment constants reads, "Since Gallium doesn't support >> GL_ARB_shadow_ambient, this is always (0,0,0,0), right?" > I'd think so. This extension isn't in core GL (and d3d can't do it > neither), and AFAIK there's no hardware (which doesn't emulate the > shadow functionality in the fragment shader) which could actually do it. Alrighty. I just won't worry about it. I wonder if I can get my compiler to not bother asking for those values, or to do a swizzle to 0 for those. >> Another >> comment reads, "Gallium doesn't provide us with any information >> regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE," >> above the texture compare modes. I don't really like that section of >> code, but it probably can't get cleaner, right? > Yes, that's not very clean, but there doesn't seem to be an easy > solution for this. Exposing this in gallium only seems marginally > useful, since again modern hardware can't really do anything useful with > that information neither. Maybe would need to tweak the shader if > actually the "wrong" channels are used (probably shouldn't be the > driver's responsibility to do this), but I guess assuming default > LUMINANCE works just fine usually. New OGL won't have that problem... New OGL? GL3? Sweet. >> >> 7) Is there more information on the dual-source blend modes? I'm not >> sure if I can do them; might have to bug AMD for the register values. > Pretty sure most pre-DX10 hardware can't do that, the blend unit just > doesn't have access to multiple source colors. > I've attached a small patch which shows how softpipe implements it. > (But I still need to write a testcase probably for the python > statetracker to see if it actually works...). > Pretty easy really, just using pixel shader color outputs 0 and 1 for > blending (note that in this form this restricts dual source blending to > one render target, this is the same restriction DX10 enforces, and if > you look at i965 docs it actually has this restriction in hardware). Alright, I'll clean those up, maybe with a comment. >> >> 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. > Great! > > Roland > And starting to get rid of all those XXX, too. :3 ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson <mostawesomed...@gmail.com> ------------------------------------------------------------------------------ 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
