On Mon, May 7, 2018 at 11:53 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > On Mon, May 7, 2018 at 8:02 AM, Alejandro Piñeiro <apinhe...@igalia.com> > wrote: >> >> Hi Jason, >> >> as part of the ARB_gl_spirv work, we are doing the linking based on the >> nir shader that comes from spirv_to_nir. On some cases, >> nir_lower_wpos_ytransform introduces a new uniform, >> "gl_FbWposYTransform". So as the uniform is there when we start to do >> the linking, it is treated as any other uniform, being added to the >> UniformStorage, accessible through the OpenGL API and so on. Something >> that I understand that we don't want. On GLSL this is not a problem >> because the linking is done based on MESA/IR, then the IR is converted >> to NIR, and the lowering adds the uniform based on the NIR shader, >> really after the linking. >> >> The first solution I thought was just mark the uniform with a special >> location [1]. It would need to be a negative value, not -1 that is >> already reserved for not-assigned locations (we still have some cases >> for those, even if in general ARB_gl_spirv makes explicit location >> mandatory). So it would be a new negative value, like lets say -5. So >> then on the linking, if the uniform location has this value, the uniform >> is skipped. >> >> After checking that this solution worked (although I only tested with >> some tests), I started to search for an alternative, as this solution >> seemed too hacky. > > > It does seem a bit hacky, yes. > >> >> But this lowering needs to be run before nir_lower_io, >> and nir_lower_io is part of the uniform lowering. So I didn't see really >> reasonable to do a nir_lower_io without nir_lower_wpos_ytransform, do >> the linking, and then execute again nir_lower_io/nir_lower_wpos_transform. > > > This is all a bit sticky. One observation is that the newly added uniform > makes usage of the token system. Are tokens no longer used with SPIR-V? I > guess they are kind-of an old mechanism to handle the crufty ARB program > parameters. However, you could have -5 mean "It uses a token" > > Another option would be to use a system value instead of a uniform. We can > then convert it to a uniform in the back-end. We have a few places where we > do things like this for compute shaders. >
fwiw, I originally used the token mechanism because mesa/st was already injecting the value into the uniform state (and I'm not sure the pipe driver is even aware where it is offhand) I suppose an easy thing to do for now is make this configurable to either use gl_FbWposYTransform or a system value. This way the gallium drivers could continue to use gl_FbWposYTransform. BR, -R > I don't have a lot of good ideas or strong opinions, I'm afraid. :-( Maybe > Ken has some? > > --Jason > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
