For the most part in gallium we've treated fragment vs vertex as part of the function name rather than as an argument, so this is consistent.
So far it seems hardware isn't very regular at this granularity -- it's not like you just end up doing the same thing for fragment shaders/const-buffers/samplers/textures as you do for the vertex equivalents. The example of passing shader unit as an argument which we have at the moment is constant buffers - in svga and i965 these get split up almost immediately and handled by different paths throughout the driver. If you look at other fragment vs. vertex code (eg shaders) in the drivers, typically they are quite divergent as well. On balance, my preference at this point is to keep distinct entrypoints for each unit... Keith ________________________________________ From: José Fonseca [jfons...@vmware.com] Sent: Monday, November 30, 2009 10:51 AM To: Michal Krol Cc: Keith Whitwell; Roland Scheidegger; mesa3d-dev Subject: Re: [Mesa3d-dev] [PATCH] Add entrypoints for setting vertex texture state Sorry for popping out so late in the game, but I just realized this now while working in related code: instead of adding new entrypoints, wouldn't it be better to keep the current ones, but add an argument, PIPE_SHADER_xxx ? This would simplify both state tracker and pipe drivers considerably, since they could keep all state in arrays of [PIPE_SHADER_TYPES] dimension. Obviously we could/should do the same for shaders too, for the same reasons and consistency. Otherwise by the time we have geometry shaders we'll have a very extensive interface, and a lot of boilerplate code... Jose On Mon, 2009-11-30 at 04:51 -0800, michal wrote: > Attached an updated patch. > > * Increased PIPE_MAX_VERTEX_SAMPLERS to 16. > * Removed PIPE_CAP_MAX_VERTEX_TEXTURES since there's already an > equivalent PIPE_CAP_MAX_VERTEX_TEXTURE_UNITS. > * Added PIPE_CAP_MAX_COMBINED_SAMPLERS to query maximum texture image > units accessible from vertex and fragment shaders combined. > > > Michal Krol pisze: > > That means we need an additional cap bit to support > > GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS because it's no longer a simple sum of > > max vertex and fragment samplers. For i965 max vertex/fragment/combined > > samplers would be then 16. > > > > -- > > Michal Krol > > ________________________________________ > > Od: Keith Whitwell > > Wysłano: 28 listopada 2009 00:40 > > Do: Michal Krol; Roland Scheidegger > > DW: mesa3d-dev > > Temat: RE: [Mesa3d-dev] [PATCH] Add entrypoints for setting vertex texture > > state > > > > The i965 can surely do 16, though maybe shared with the fragment shaders. > > > > Keith > > ________________________________________ > > From: michal [mic...@vmware.com] > > Sent: Friday, November 27, 2009 2:20 PM > > To: Roland Scheidegger > > Cc: Keith Whitwell; mesa3d-dev > > Subject: Re: [Mesa3d-dev] [PATCH] Add entrypoints for setting vertex > > texture state > > > > Roland Scheidegger pisze: > > > >> On 27.11.2009 19:32, michal wrote: > >> > >> > >>>> Why is the MAX here smaller than for fragment samplers? Doesn't GL > >>>> require them to be the same, because GL effectively binds the same set > >>>> of sampler states in both cases? > >>>> > >>>> Can you take a closer look at what the GL state tracker would have to do > >>>> to expose this functionality and make sure it's valid? > >>>> > >>>> > >>>> > >>>> > >>> It's all good. There is GL_MAX_VERTEX_TEXTURE_UNITS that tells how many > >>> samplers can be used in a vertex shader. Anything above that is used > >>> only with fragment shaders and ignored for vertex shaders. > >>> > >>> > >> I fail to see though why the limit needs to be that low. All modern > >> hardware nowadays can use the same number of texture samplers for both > >> fragment and vertex shading (it's the same sampler hardware, after all). > >> Some older hardware (typically non-unified, D3D9 shader model 3 > >> compliant) though indeed only had limited support for this (like the > >> GeForce 6/7 series) probably only supporting 4 (can't remember exactly), > >> though other hardware never implemented it despite d3d9 sm3 requiring it > >> (thanks to a api loophole). > >> > >> > >> > > > > Wow, it looks like I need to upgrade my hardware. I thought 4 vertex > > texture units is generous. I have no problem with setting that limit to, > > say, 16. > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > > trial. Simplify your report design, integration and deployment - and focus > > on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Mesa3d-dev mailing list > > Mesa3d-dev@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
