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
