On 11.01.2010 22:03, Zack Rusin wrote: > 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. Hmm, maybe.
> >>> 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 :) Ah, that's why it doesn't make much sense :-). I'm not sure what requirements got them to these levels. I definitely think those 3 dx9 levels are very odd and don't even make sense for d3d only, much less for gallium. For example, requires at least max aniso 16? You got to be kidding, aniso spec is so fuzzy you can pass any cheap point filter as compliant (well almost) anyway, so it doesn't make any sense (plus, this only really enhances filtering quality, it makes absolutely zero difference for writing applications). I think the retrofit of 9_1, 9_2, 9_3 to some arbitrary DX9 versions doesn't match hardware really neither. The most distinguishable feature of DX9.0c (which was the last version IIRC) was definitely SM 3.0, but of course like everything else (multiple render targets, etc.) it was optional. I think for gallium it would make way more sense to expose only 2 feature levels - basically drop 9_1, and additionally bump 9_3 to include SM 3.0 (I wonder if that's not just a typo there, after all the model is called "ps_4_0_level_9_3" unlike the others which are called 9_1 only). Though granted nv20/25 can't do separate alpha blend (but it can't do fragment shaders neither really so I don't know how well that driver is ever going to work), i915 may not be able to do occlusion queries (not sure if hw can't do it but the current driver doesn't implement it), everybody (I think) can do mirror_once, and I don't know what overlapping vertex elements are. > >> 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. Though thinking about this, maybe we should keep a level below lowest dx9 feature level, since gallium drivers exist which are pretty low on the feature scale (like the nv04/10/20). I don't know how well they'll ever going to work, since they'd need the fixed function fragment operations out of tgsi, but maybe we shouldn't prevent it by forcing them to announce support of fragment shaders. > >>> 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. I consider that differently, because the hardware gallium is targeted at either supports vertex shaders or no vertex shading hardware at all (but not fixed function TNL hardware). Obviously, you can't have any applications which don't require any sort of vertex shading, so you always need a fallback, and it doesn't matter if the state originally was fixed function or it was a vertex shader. But that's quite different with geometry shaders, apps will not use geometry shaders just fine if they aren't supported. > >>> 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. Hmmm. Unsure of i915, radeons back to first gen could support it, and I'm pretty sure pre-DX9 nv hardware could do it as well. > >>> 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. Yeah. Again, I believe all hardware which can do SM 2.0 pretty much can do it. Maybe they just forgot to include it in the first released DX9 revision or something like that. Radeons could definitely do it earlier (DX8 hardware), nvidia introduced support for it with their so-called DX9 hardware (GeForce FX series), as did intel with 915. It is possible some exotic hardware can't do it, however. > >>> 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. It is also worth mentioning that some hardware (radeons) can't actually do all of it as required by GL 2.0. DX9 (afaik) only required different stencil funcs, but not different reference values/masks. Both intel and nvidia can do the full GL 2.0 two-sided stencil state with their SM 2.0 hardware. > >> 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. I'm pretty sure hardware will still support it. If not then yes I'd guess we could use util code to do it in the geometry shader (or the drivers have to do it - the i965 driver currently already uses the geometry shader stage to do things like that). In any case, I think we still need to say it's supported. > > 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. I dunno but I feel MS requirements aren't those which make sense for us. Some look pretty bonkers to me (like the aniso requirement), but more importantly they don't match hw levels well, and even less so GL requirements. Now the higher levels (since DX10) make sense to me (also because the interesting GL extensions from that area are pretty much just ports of DX10 stuff, so it should match both hardware and GL pretty well). Actually, for the lower DX9 levels, it probably shouldn't say GL 2.x. Gallium is just fine for hardware which can't really do GLSL, as long as the hardware has some kind of programmable fragment pipeline (so it's more like driver should support ARB_fp). From that (first gen DX) generation of graphics hardware, neither intel (i915), nor AMD (r300/r400) can really support GL 2.0 as their fragment pipeline isn't flexible enough (nvidia can do it but it's very slow). AMD managed to say GL 2.0 in their extension string, but they just use some clever compiler to make it halfway work, as long as your glsl shaders are simple enough. They can do ARB_fp however (which is really pretty equivalent to DX9 SM 2.0), and typically support about GL 1.5 with some extensions really (the other problem they all have with GL 2.0 is they can't do ARB_texture_npot usually, at least not fully). Anyway, I don't think these feature levels work very well at the lower levels if you don't want to make GL a second class citizen, I think you'd still need some of the caps. Roland ------------------------------------------------------------------------------ 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
