On Monday 11 January 2010 15:17:00 Roland Scheidegger wrote: > > - extra mirror wrap modes - i don't think mirror repeat was ever > > supported and mirror clamp was removed in d3d10 but it seems that some > > hardware kept support for those > > Mirror repeat is a core feature in GL since 1.4 hence we can't just drop > it.
I wasn't suggesting that. I was just pointing out what happens with it from the D3D side. > I think all hardware we'd ever care about would support it. mirror > clamp / mirror clamp to edge are only an extension, though > (ATI_texture_mirror_once). (I think the dx mirror once definition is > probably mirror_clamp_to_edge in opengl parlance). That's possible. As mentioned I'm not really sure what to do with this feature. > > - shadow maps - it's more of an "researched guess" since it's largely > > based on a format support, but as far as i can tell all d3d10 hardware > > supports it, earlier it varies (e.g. nvidia did it for ages) > > Required for GL 1.4. I thought it was pretty much required for d3d > sm2.0, though you're right you could probably just not support the > texture format there. Anyway, most hardware should support it, I believe > even those which didn't really supported it at DX9 SM 2.0 time supported > it (chips like radeon r300 lacked the hw to do the comparison in the > texture unit, but it can be more or less easily implemented in the pixel > shader, though the implementation will suck as it certainly won't do PCF > just use some point sampling version - unless you're willing to do a > much more complex implementation in the pixel shader, but then on this > generation of hardware you might exceed maximum shader length). I > believe all hardware supporting SM 2.0 could at least do some sampling > of depth textures, though possibly only 16 bit and I'm not sure > filtering worked in all cases. Yes, but the issue is that I'm not sure how to represent it from a feature level case. Are you saying we should just enable it for all feature levels? That'd be nice. > > I think the other stuff is acceptable. Take a look at the docs and let me > > know what you think. > > What is feature level 1 useful for? I thought we'd really wanted DX9 > level functionality as a bare minimum. GL2.x certainly needs cards > supporting shader model 2 (and that is a cheat, in reality it would be > shader model 3). The main issue was having something without hardware vs in the feature levels. It was supposed to be whatever the current i915 driver currently supports, but yea, I think it doesn't make sense and level 2 should be minumum. > Also, I don't quite get the shader model levels. I thought there were > mainly two different DX9 versions, one with sm 2.0 the other with 3.0, > with noone caring about other differences (as most stuff was cappable > anyway). However, you've got 3 and all of them have 2.0 shader model? As mentioned this is based on the D3D feature level concept. It's the first link I put in the the references: http://msdn.microsoft.com/en-us/library/ee422086(VS.85).aspx#Overview It's there because that's what Microsoft defined as feature level and I'm assuming it's because they had a good need for it :) > More comments below. > > > +static const enum pipe_feature_level > > +i915_feature_level(struct pipe_screen *screen) > > +{ > > + return PIPE_FEATURE_LEVEL_1; > > +} > > What's the reason this is not feature level 2? Yea, I was winging it for all the drivers because I couldn't be bothered to do a cross-section of what the hardware can teorethically support and what the driver actually supports so I just put level 1 or whatever felt close enough in all of them. The maintainers would have to actually do the right thing there. > > ------------------------------------------------------------------------ > > > > Profile 7 (2009) 6 (2008) 5 > > (2006) 4 (2004) 3 (2003) 2 (2002) 1 (2000) > > Fragment Shader Yes Yes Yes > > Yes Yes Yes Yes > > DX 7 didn't have any shader model IIRC. DX8/8.1 introduced shader models > 1.0-1.3/1.4. Yea, that level should be gone. > > > Vertex Shader Yes Yes Yes > > Yes Yes Yes No > > I don't think we care for this. Since the gallium API requires vertex > shaders anyway, that's just a YES in all cases, regardless if it's > executed by hardware or not. Isn't that the same discussion with geometry shaders? We could support it everywhere like vertex shader. The snafu is what happens when people use it as fallback for other features. > > No Alpha-to-coverage Yes Yes > > Yes No No No No > > This is required for even GL 1.3, if ARB_multisample is supported. > Though afaik there's tons of hardware out there which doesn't support > it, maybe those are even compliant as the gl spec is a bit vague here > how coverage values need to be calculated... That'd be good to figure out. But again, above is from the D3D features table so I'm not sure how reliable it's going to be. > > Extended Formats*(BGRA, etc.) Yes Optional > > Optional > > Yes Yes Yes No 10-bit XR High > > Color Format Yes Optional Optional N/A > > > > N/A N/A N/A Max Texture Dimension > > > > 16384 8192 8192 4096 2048 > > 2048 2048 Max > > Cubemap Dimension 16384 8192 8192 > > 4096 512 > > 512 512 Max Volume Extent 2048 > > > > 2048 2048 256 256 256 > > 256 > > Max Texture Repeat 16384 8192 8192 > > 8192 2048 > > 128 128 Max Anisotropy 16 > > > > 16 16 16 16 2 > > > > 0 Max Primitive Count 2^32 2^32 > > 2^32 1048575 > > 1048575 65535 65535 Simultaneous Render Targets 8 > > > > 8 8 4 1 1 > > > > 1 Occlusion Queries Yes Yes > > Yes Yes Yes No No > > Occlusion queries are required for OGL 1.5. Cool but are they universally supported? http://msdn.microsoft.com/en- us/library/ee416168(VS.85).aspx says that this level doesn't support them. > > > Separate Alpha Blend Yes Yes Yes > > > > Yes Yes No No > > Required for OGL 1.4 (and different blend equations in addition of blend > functions for 2.0). I thought though it was required for DX9 too? Microsoft disagrees in that first link I posted. > > No No Two sided stencil Yes > > Yes Yes No No > > No No > > This is also a core GL 2.0 feature. Also, you've listed it there as > feature level 5 feature but the mesa state tracker enables it at feature > level 4 Yea, as mentioned I don't really know what to do with two-sided stencil. > Oh, no longer supported in DX10? I guess that's just because you have to > implement them yourself in the geometry shader right? Right. > We'd still need to support them I guess in the drivers for GL. Or implement them in util's with geometry shaders :) It's mainly a question of whether hardware will support it, since Microsoft dropped it I'd be careful. All in all, I agree the first feature level is pretty bonkers, but I wanted to have something without explicit hardware vertex shaders. The rest is really what Microsoft requires, but for the stuff I pointed out it's obviously very murky and a matter of discussion. In the end we can define whatever feels right if it covers enough cases. z ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
