Re: [Mesa3d-dev] Gallium feature levels
On Tue, 2010-01-12 at 21:37 -0800, Ben Skeggs wrote: > On Tue, 2010-01-12 at 11:01 -0500, Younes Manton wrote: > > On Tue, Jan 12, 2010 at 9:44 AM, Keith Whitwell wrote: > > > On Tue, 2010-01-12 at 06:33 -0800, Roland Scheidegger wrote: > > >> >>> > > >> >>> 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. > > > > > > The base level of gallium functionality included fragment shaders from > > > the start, these early nv drivers don't really change that. > > > > > > In my view these are a speculative bet that with a lot of effort it is > > > possible to turn shaders back into fixed-function, but supporting that > > > isn't a design goal for gallium as a whole. > > > > > > Keith > > > > Just my opinion, > > > > I wouldn't count on nv04-nv20 actually staying in gallium. At some > > point we wanted to experiment with shaders on fixed func, but I don't > > think anyone is really motivated or optimistic that it will turn out > > well. They're already rotting as it is. Francisco Jerez is working on > > a classic Mesa driver for these and if/when they're worth pushing to > > master I'd expect the gallium drivers to be axed. > Agreed. IMO they could be removed now, I don't see them ever being > done, and Francisco's drivers are shaping up quite nicely already. That'd be fine with me too. Keith -- 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
Re: [Mesa3d-dev] Gallium feature levels
On Tue, 2010-01-12 at 11:01 -0500, Younes Manton wrote: > On Tue, Jan 12, 2010 at 9:44 AM, Keith Whitwell wrote: > > On Tue, 2010-01-12 at 06:33 -0800, Roland Scheidegger wrote: > >> >>> > >> >>> 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. > > > > The base level of gallium functionality included fragment shaders from > > the start, these early nv drivers don't really change that. > > > > In my view these are a speculative bet that with a lot of effort it is > > possible to turn shaders back into fixed-function, but supporting that > > isn't a design goal for gallium as a whole. > > > > Keith > > Just my opinion, > > I wouldn't count on nv04-nv20 actually staying in gallium. At some > point we wanted to experiment with shaders on fixed func, but I don't > think anyone is really motivated or optimistic that it will turn out > well. They're already rotting as it is. Francisco Jerez is working on > a classic Mesa driver for these and if/when they're worth pushing to > master I'd expect the gallium drivers to be axed. Agreed. IMO they could be removed now, I don't see them ever being done, and Francisco's drivers are shaping up quite nicely already. Ben. > > -- > 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 -- 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
Re: [Mesa3d-dev] Gallium feature levels
On Tue, Jan 12, 2010 at 9:44 AM, Keith Whitwell wrote: > On Tue, 2010-01-12 at 06:33 -0800, Roland Scheidegger wrote: >> >>> >> >>> 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. > > The base level of gallium functionality included fragment shaders from > the start, these early nv drivers don't really change that. > > In my view these are a speculative bet that with a lot of effort it is > possible to turn shaders back into fixed-function, but supporting that > isn't a design goal for gallium as a whole. > > Keith Just my opinion, I wouldn't count on nv04-nv20 actually staying in gallium. At some point we wanted to experiment with shaders on fixed func, but I don't think anyone is really motivated or optimistic that it will turn out well. They're already rotting as it is. Francisco Jerez is working on a classic Mesa driver for these and if/when they're worth pushing to master I'd expect the gallium drivers to be axed. -- 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
Re: [Mesa3d-dev] Gallium feature levels
On Tue, 2010-01-12 at 06:33 -0800, Roland Scheidegger wrote: > >>> > >>> 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. The base level of gallium functionality included fragment shaders from the start, these early nv drivers don't really change that. In my view these are a speculative bet that with a lot of effort it is possible to turn shaders back into fixed-function, but supporting that isn't a design goal for gallium as a whole. Keith -- 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
Re: [Mesa3d-dev] Gallium feature levels
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 rea
Re: [Mesa3d-dev] Gallium feature levels
The hybrid approach is appealing to me, since Radeons are so damn quirky, but anything not requiring me to set up the dedicated fog block wins my vote. ~ C. On Mon, Jan 11, 2010 at 1:50 PM, Jakob Bornecrantz wrote: > > On 11 jan 2010, at 21.17, Zack Rusin wrote: > >> On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote: >>> On 11 jan 2010, at 17.49, Zack Rusin wrote: I think the other stuff is acceptable. Take a look at the docs and let me know what you think. >>> >>> Hmm I don't think you should remove the CAPs but instead just say if >>> level X then CAPs Y,Z,W,Q are assumed to be present. This way the >>> hardware that fall between the cracks can expose one level plus the >>> extra CAPs it can do. >> >> Would that be useful for anything? Or do you mean feature level + >> exceptions, >> oterhwise what's the point of feature levels if nothing supports >> them fully. > > Take the i915 for instance it can do level 1, but it can also do real > npot textures. Not just for last_level == 0. > > Ian said a lot more and better > >> >>> Another thing level 3 and below harder can not do ARB_npot but they >>> can do NV_texture_rect, the only hardware we have drivers that this >>> matter for is nv30 (I think) and r300. >> >> Yes, that's what the "unnormalized coords" part is about :) > > What I meant is that in st_extensions.c you check for feature level > > 1 and set ARB_npot if that is true. But it isn't untill level 4 "2D > textures pot if MipCount >1" is set to no. So to make the test correct > and cover the i915 case the test should be level >= 4 or CAP_NPOT. > > Cheers Jakob. > > -- > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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
Re: [Mesa3d-dev] Gallium feature levels
On 11 jan 2010, at 21.17, Zack Rusin wrote: > On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote: >> On 11 jan 2010, at 17.49, Zack Rusin wrote: >>> I think the other stuff is acceptable. Take a look at the docs and >>> let me know >>> what you think. >> >> Hmm I don't think you should remove the CAPs but instead just say if >> level X then CAPs Y,Z,W,Q are assumed to be present. This way the >> hardware that fall between the cracks can expose one level plus the >> extra CAPs it can do. > > Would that be useful for anything? Or do you mean feature level + > exceptions, > oterhwise what's the point of feature levels if nothing supports > them fully. Take the i915 for instance it can do level 1, but it can also do real npot textures. Not just for last_level == 0. Ian said a lot more and better > >> Another thing level 3 and below harder can not do ARB_npot but they >> can do NV_texture_rect, the only hardware we have drivers that this >> matter for is nv30 (I think) and r300. > > Yes, that's what the "unnormalized coords" part is about :) What I meant is that in st_extensions.c you check for feature level > 1 and set ARB_npot if that is true. But it isn't untill level 4 "2D textures pot if MipCount >1" is set to no. So to make the test correct and cover the i915 case the test should be level >= 4 or CAP_NPOT. Cheers Jakob. -- 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
Re: [Mesa3d-dev] Gallium feature levels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zack Rusin wrote: > On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote: >> On 11 jan 2010, at 17.49, Zack Rusin wrote: >>> I think the other stuff is acceptable. Take a look at the docs and >>> let me know >>> what you think. >> Hmm I don't think you should remove the CAPs but instead just say if >> level X then CAPs Y,Z,W,Q are assumed to be present. This way the >> hardware that fall between the cracks can expose one level plus the >> extra CAPs it can do. > > Would that be useful for anything? Or do you mean feature level + exceptions, > oterhwise what's the point of feature levels if nothing supports them fully. I think he's suggesting that we use the GL model for the GL driver: feature level + added functionality. The D3D model for exposing functionality if fundamentally pretty different from the GL model. The D3D model wants to expose *only* the lowest common denominator in order to provide uniformity. The GL model seeks to provide common functionality while still encouraging product differentiation. The GL model is increasingly heading in this direction, and I think it's a good model to follow. Many, if not all, of the features in GL version 3.x that might be available on 3.(x-1) hardware are exposed as extension with the same function and enum names. This makes it easier to say, "I can run on GL 3.x + GL_ARB_foo or GL 3.x+1." -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktLmBsACgkQX1gOwKyEAw/7tgCglay3aVLg722T54jjjLkXRDHm 1vYAoJlMdjT+Ez75RWs2WiLkBMfxGYBA =PvNg -END PGP SIGNATURE- -- 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
Re: [Mesa3d-dev] Gallium feature levels
On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote: > On 11 jan 2010, at 17.49, Zack Rusin wrote: > > I think the other stuff is acceptable. Take a look at the docs and > > let me know > > what you think. > > Hmm I don't think you should remove the CAPs but instead just say if > level X then CAPs Y,Z,W,Q are assumed to be present. This way the > hardware that fall between the cracks can expose one level plus the > extra CAPs it can do. Would that be useful for anything? Or do you mean feature level + exceptions, oterhwise what's the point of feature levels if nothing supports them fully. > Another thing level 3 and below harder can not do ARB_npot but they > can do NV_texture_rect, the only hardware we have drivers that this > matter for is nv30 (I think) and r300. Yes, that's what the "unnormalized coords" part is about :) 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
Re: [Mesa3d-dev] Gallium feature levels
On Monday 11 January 2010 15:22:43 Luca Barbieri wrote: > The feature levels in the attached table don't apply exactly to all > hardware. > > For instance: > 1. Two sided stencil is supported from NV30/GeForce FX > 2. Triangle fans and point sprites are supported in hardware on NV50 > (according to Nouveau registers) > 3. Alpha-to-coverage should be supported on R300 and NV30 > 4. Non-POT mipmapped textures and non-POT cubemaps are probably > supported earlier than in the table in actual cards I'm guessing each with its quirks given that Microsoft just doesn't require them for each of the respective levels. It's possible that GL requirements forced those upon IHV in certain cases (Roland mentioned a few that probably apply) but if that's the case we could certainly update the entire table. > Shaders also have card specific extensions such as vertex shader > texturing on NV40 and added instruction predication support (see the > GL_NV_* extensions). > > Thus the attached patch as-is will disable functionality that the > hardware actually supports (not having two sided stencil in particular > would hurt). > > Also, the feature levels seem set mostly wrong: They're just stubs, you'd have to fill them in for your drivers. As I mentioned in the response to Roland I didn't feel like looking up each hardware spec and intersecting that with what's in each driver before we even decided what each feature level means. > How about keeping the caps, but adding helper functions that the > drivers can use for the various API levels, so they need less cases in > their get_param switches? > The feature level are likely at least somewhat API-specific anyway, so > maybe it would be better for each API to determine them itself from > the separate caps exposed by the drivers. That doesn't win us anything, does it? It's just more code all around rather than less. Feature levels + exceptions (the problematic things i've mentioned in the last email) could possibly make sense, I don't know. > Anyway, there are only 3 companies with significant market share, so > one may as well directly use the nVidia/ATI/Intel architecture version > as the feature level (which is what most commercial games probably do > anyway). Well they don't have to because they use D3D version which defines those for them (aka. what the table is based on). 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
Re: [Mesa3d-dev] Gallium feature levels
On 11 jan 2010, at 17.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 > - 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) > > I think the other stuff is acceptable. Take a look at the docs and > let me know > what you think. Hmm I don't think you should remove the CAPs but instead just say if level X then CAPs Y,Z,W,Q are assumed to be present. This way the hardware that fall between the cracks can expose one level plus the extra CAPs it can do. Another thing level 3 and below harder can not do ARB_npot but they can do NV_texture_rect, the only hardware we have drivers that this matter for is nv30 (I think) and r300. Cheers Jakob. -- 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
Re: [Mesa3d-dev] Gallium feature levels
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 a
Re: [Mesa3d-dev] Gallium feature levels
The feature levels in the attached table don't apply exactly to all hardware.
For instance:
1. Two sided stencil is supported from NV30/GeForce FX
2. Triangle fans and point sprites are supported in hardware on NV50
(according to Nouveau registers)
3. Alpha-to-coverage should be supported on R300 and NV30
4. Non-POT mipmapped textures and non-POT cubemaps are probably
supported earlier than in the table in actual cards
Shaders also have card specific extensions such as vertex shader
texturing on NV40 and added instruction predication support (see the
GL_NV_* extensions).
Thus the attached patch as-is will disable functionality that the
hardware actually supports (not having two sided stencil in particular
would hurt).
Also, the feature levels seem set mostly wrong:
+static const enum pipe_feature_level
+nv40_screen_feature_level(struct pipe_screen *screen)
+{
+ return PIPE_FEATURE_LEVEL_2;
+}
+static const enum pipe_feature_level
+nv50_screen_feature_level(struct pipe_screen *screen)
+{
+ return PIPE_FEATURE_LEVEL_2;
+}
NV40 is feature level 4 and NV50 is at least 5.
How about keeping the caps, but adding helper functions that the
drivers can use for the various API levels, so they need less cases in
their get_param switches?
The feature level are likely at least somewhat API-specific anyway, so
maybe it would be better for each API to determine them itself from
the separate caps exposed by the drivers.
Anyway, there are only 3 companies with significant market share, so
one may as well directly use the nVidia/ATI/Intel architecture version
as the feature level (which is what most commercial games probably do
anyway).
--
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
Re: [Mesa3d-dev] Gallium feature levels
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 DX11DX10.1
> DX10/GL3.2 DX9.2 DX9.1 DX9.0DX7.0
> GL4.0 GL3.2+ GL3.2
> GL3.0 GL2.x GL2.xGL2.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_
[Mesa3d-dev] Gallium feature levels
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 - 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) I think the other stuff is acceptable. Take a look at the docs and let me know what you think. z From 962994ad9f05b6ae219f839082d4743e7d2a70fe Mon Sep 17 00:00:00 2001 From: Zack Rusin Date: Mon, 11 Jan 2010 12:34:26 -0500 Subject: [PATCH] gallium: implement feature levels a broader way of figuring out features of the hardware we're running on --- src/gallium/docs/source/gallium_feature_levels.rst | 69 src/gallium/docs/source/screen.rst |5 ++ src/gallium/drivers/cell/ppu/cell_screen.c | 27 ++-- src/gallium/drivers/i915/i915_screen.c | 21 ++ src/gallium/drivers/i965/brw_screen.c | 21 ++ src/gallium/drivers/identity/id_screen.c | 10 +++ src/gallium/drivers/llvmpipe/lp_screen.c | 28 ++-- src/gallium/drivers/nv04/nv04_screen.c | 29 ++-- src/gallium/drivers/nv10/nv10_screen.c | 25 ++- src/gallium/drivers/nv20/nv20_screen.c | 25 ++- src/gallium/drivers/nv30/nv30_screen.c | 29 ++-- src/gallium/drivers/nv40/nv40_screen.c | 28 ++-- src/gallium/drivers/nv50/nv50_screen.c | 28 ++-- src/gallium/drivers/r300/r300_screen.c | 60 +++-- src/gallium/drivers/softpipe/sp_screen.c | 28 ++-- src/gallium/drivers/svga/svga_screen.c | 28 ++-- src/gallium/drivers/trace/tr_screen.c | 20 ++ src/gallium/include/pipe/p_defines.h | 29 + src/gallium/include/pipe/p_screen.h|5 ++ src/mesa/state_tracker/st_cb_drawpixels.c |4 +- src/mesa/state_tracker/st_extensions.c | 23 --- 21 files changed, 231 insertions(+), 311 deletions(-) create mode 100644 src/gallium/docs/source/gallium_feature_levels.rst diff --git a/src/gallium/docs/source/gallium_feature_levels.rst b/src/gallium/docs/source/gallium_feature_levels.rst new file mode 100644 index 000..fcde68d --- /dev/null +++ b/src/gallium/docs/source/gallium_feature_levels.rst @@ -0,0 +1,69 @@ +Profile 7 (2009)6 (2008)5 (2006)4 (2004)3 (2003)2 (2002) 1 (2000) + +API Support DX11DX10.1 DX10/GL3.2 DX9.2 DX9.1 DX9.0DX7.0 +GL4.0 GL3.2+ GL3.2 GL3.0 GL2.x GL2.xGL2.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 +Vertex Shader Yes Yes Yes Yes Yes Yes No +Geometry Shader Yes Yes Yes No No No No +Stream Out Yes Yes Yes No No No No +Compute Shader
