On 11.01.2010 18:49, Zack Rusin wrote:
> Hey,
>
> knowing that we're starting to have serious issues with figuring out what
> features the given device supports and what api's/extensions can be
> reasonably
> implemented on top of it I've spent the weekend trying to define feature
> levels. Feature levels were effectively defined by the Direct3D version
> numbers.
> Attached is a patch and documentation for the feature levels. I'm also
> attaching gallium_feature_levels.rst file which documents what each feature
> level means and what apis can be reasonably supported by each (I figured it's
> going to be easier to look at it outside the diff).
>
> There's a few features that are a bit problematic, in no particular order:
> - unnormalized coordinates, we don't even have a cap for those right now but
> since that feature doesn't exist in direct3d (all coords are always
> normalized
> in d3d) the support for it is hard to define in term of a feature level
> - two-sided stencil - d3d supports it in d3d10 but tons of hardware supported
> it earlier
> - 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 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).
> - 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.
>
> 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).
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?
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?
> +static const enum pipe_feature_level
> +nv30_screen_feature_level(struct pipe_screen *screen)
> +{
> + return PIPE_FEATURE_LEVEL_1;
> +}
> +
Hmm in theory this should be feature level 2. Maybe the driver doesn't
quite cut it though...
> +static const enum pipe_feature_level r300_feature_level(
> + struct pipe_screen* pscreen)
> +{
> + if (r300screen->caps->is_r500) {
> + return PIPE_FEATURE_LEVEL_2;
> + } else {
> + return PIPE_FEATURE_LEVEL_1;
> + }
> +}
Shouldn't one be feature level 3 (or maybe 4?) the other 2?
> ------------------------------------------------------------------------
>
> Profile 7 (2009) 6 (2008) 5 (2006)
> 4 (2004) 3 (2003) 2 (2002) 1 (2000)
>
> API Support DX11 DX10.1
> DX10/GL3.2 DX9.2 DX9.1 DX9.0 DX7.0
> GL4.0 GL3.2+ GL3.2
> GL3.0 GL2.x GL2.x GL2.x
> VG VG VG
> VG VG VG VG
> CL1.0 CL1.0 CL1.0
>
> Shader Model 5.0 4.x 4.0
> 2.0 2.0 2.0 1.0
>
> 4_0_level_9_3 4_0_level_9_1 4_0_level_9_1
>
> 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.
> 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.
> Geometry Shader Yes Yes Yes
> No No No No
> Stream Out Yes Yes Yes
> No No No No
> Compute Shader Yes Optional
> Optional No No No No
> Hull and Domain Shaders Yes No No
> No No No No
> Texture Resource Arrays Yes Yes Yes
> No No No No
> Cubemap Resource Arrays Yes Yes No
> No No No No
> BC4/BC5 Compression Yes Yes Yes
> No No No No
> BC6H/BC7 Compression Yes No No
> No No No 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...
> 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.
> 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? AFAIK
the last hardware which didn't support it was nv20/25, which was only
DX8 / SM 1.3.
> Mirror Once Yes Yes Yes
> Yes Yes No No
> Overlapping Vertex Elements Yes Yes Yes
> Yes Yes No No
> Independent Write Masks Yes Yes Yes
> Yes No No No
I thinks this one should probably also include independent blend enables.
> Instancing Yes Yes Yes
> Yes No No No
> Independent blend modes Yes Yes No
> No No No No
> Dual-source blending Yes Yes Yes
> No No 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
.
> Cube textures dimensions pot No No No
> Yes Yes Yes Yes
> 2D textures pot if MipCount >1 No No No
> No Yes Yes Yes
> DXTC / S3TC (*1) Yes Yes Yes
> Yes Yes Yes Yes
> Point Sprites No No No
> Yes Yes Yes Yes
Oh, no longer supported in DX10? I guess that's just because you have to
implement them yourself in the geometry shader right? We'd still need to
support them I guess in the drivers for GL.
> Unnormalized texture coordinates N/A N/A N/A
> N/A N/A N/A N/A
> Triangle fans No No No
> Yes Yes Yes Yes
> Occlusion query Yes Yes Yes
> Yes Yes Yes No
> Shadow maps (*2) Yes Yes Yes
> No No No No
> Guard band clipping (*3) N/A N/A N/A
> N/A N/A N/A N/A
> Texture mirror clamp No No No
> Yes Yes Yes No
> Texture mirror repeat No No No
> No No No No
>
>
>
> *1) There is no distinction between pre-multiplied alpha or non-premultiplied
> alpha in Direct3D 10. DXT formats have been replaced by BC formats, so DXT1
> == BC1,
> DXT2,DXT3 == BC2 and DXT4,DXT5 == BC3 (bc for block compression)
> *2) There's lots of ways of performing shadow mapping but what we refer to is
> simply
> the ability to sample & filter from a depth texture. This ability is format
> dependent
> and therefore doesn't strickly adhere to the feature levels but all major
> vendors
> (NVIDIA, AMD, Intel) seem to support it in their DX10 level GPUs.
> *3) It's part of the functionality a driver can support or not. At least for
> DX9 level
> drivers. I'm not sure what happened with it afterwards.
>
> References:
> http://msdn.microsoft.com/en-us/library/ee422086(VS.85).aspx#Overview
> http://msdn.microsoft.com/en-us/library/ee416168(VS.85).aspx
> http://msdn.microsoft.com/en-us/library/ee416166(VS.85).aspx
> http://msdn.microsoft.com/en-us/library/ee415655(VS.85).aspx
> http://msdn.microsoft.com/en-us/library/ms792615.aspx
>
In short, feature level 5-7 look reasonable to me. Below that, the 3 DX9
levels look odd to me (imho there should be just two), and the lower the
level the bigger the mismatch between what d3d and OGL requires for some
version. Level 1 I don't really get at all (with its apparently fixed
function DX but shader based OGL requirements), though maybe something
like this is needed for things like the nv04/nv10 drivers. I haven't
looked at them closely but I really wonder how they'll implement all
those fragment shaders in their 2 stage fixed function (dual-mul + add
capable IIRC) fragment stage...
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
