Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.
On 01/17/2014 01:57 PM, Chris Forbes wrote: Ken, Assuming the caches don't completely derail things, you ought to be able to make this work with pretty minimal impact: - Keep the low four bits of the sampler index where they are - If the 5th bit is set: - Force message header on - Add 16*sizeof(sampler_state) to the copy of r0.3 in the header. Hey, thanks! I forgot we get a copy of the sampler state table pointer in the r0.3 header. With that, it's totally easy. The one sad thing is that the message header field only exists on Haswell+. It's documented in the Ivybridge PRM, but empirically the PRM appears to be flat wrong. Ah well...new features on new hardware, I guess. We already mangle the copy of r0.2 in various ways for offsetting / channel select so this isn't a huge change. With 4.0/ARB_gpu_shader5 you need to emit conditional code in some cases since you don't always know the sampler index at compile time, but it's still pretty manageable. -- Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.
The test seems to work correctly with 32 textures per stage. It tests that all textures return the correct color, but the sampler state is always the same. Marek On Thu, Jan 16, 2014 at 1:28 AM, Kenneth Graunke kenn...@whitecape.org wrote: On 01/15/2014 12:56 PM, Chris Forbes wrote: Does this actually work for 16? Sampler messages' descriptor only has 4 bits for the sampler index, so it seems you'd silently lose the top bit and get the wrong sampler parameters. Oh, wow. No...no, it can't possibly work then. (Apparently that Piglit test isn't sufficient...I just glanced at it...) It looks like the Intel Windows driver has bumped this to 32 on Haswell (but not earlier). I'm guessing that they use the Sampler State Pointer field in the message /header/, instead of the Sampler Index field in the message /descriptor/. On Haswell, that changed to be relative to Dynamic State Base Address instead of General State Base Address. Which probably helps. Still, that's probably going to be kind of miserable. I'll have to look into what they're doing. NAK on patch 2. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.
On 01/17/2014 01:08 PM, Marek Olšák wrote: The test seems to work correctly with 32 textures per stage. It tests that all textures return the correct color, but the sampler state is always the same. Which is the problem. The method we're using to access samplers works fine for up to 16, but fails after that... by dropping the high-order index bits. If all the samplers are the same, the test won't notice that Ken's implementation is garbage. :( Marek On Thu, Jan 16, 2014 at 1:28 AM, Kenneth Graunke kenn...@whitecape.org wrote: On 01/15/2014 12:56 PM, Chris Forbes wrote: Does this actually work for 16? Sampler messages' descriptor only has 4 bits for the sampler index, so it seems you'd silently lose the top bit and get the wrong sampler parameters. Oh, wow. No...no, it can't possibly work then. (Apparently that Piglit test isn't sufficient...I just glanced at it...) It looks like the Intel Windows driver has bumped this to 32 on Haswell (but not earlier). I'm guessing that they use the Sampler State Pointer field in the message /header/, instead of the Sampler Index field in the message /descriptor/. On Haswell, that changed to be relative to Dynamic State Base Address instead of General State Base Address. Which probably helps. Still, that's probably going to be kind of miserable. I'll have to look into what they're doing. NAK on patch 2. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.
Ken, Assuming the caches don't completely derail things, you ought to be able to make this work with pretty minimal impact: - Keep the low four bits of the sampler index where they are - If the 5th bit is set: - Force message header on - Add 16*sizeof(sampler_state) to the copy of r0.3 in the header. We already mangle the copy of r0.2 in various ways for offsetting / channel select so this isn't a huge change. With 4.0/ARB_gpu_shader5 you need to emit conditional code in some cases since you don't always know the sampler index at compile time, but it's still pretty manageable. -- Chris On Sat, Jan 18, 2014 at 10:22 AM, Ian Romanick i...@freedesktop.org wrote: On 01/17/2014 01:08 PM, Marek Olšák wrote: The test seems to work correctly with 32 textures per stage. It tests that all textures return the correct color, but the sampler state is always the same. Which is the problem. The method we're using to access samplers works fine for up to 16, but fails after that... by dropping the high-order index bits. If all the samplers are the same, the test won't notice that Ken's implementation is garbage. :( Marek On Thu, Jan 16, 2014 at 1:28 AM, Kenneth Graunke kenn...@whitecape.org wrote: On 01/15/2014 12:56 PM, Chris Forbes wrote: Does this actually work for 16? Sampler messages' descriptor only has 4 bits for the sampler index, so it seems you'd silently lose the top bit and get the wrong sampler parameters. Oh, wow. No...no, it can't possibly work then. (Apparently that Piglit test isn't sufficient...I just glanced at it...) It looks like the Intel Windows driver has bumped this to 32 on Haswell (but not earlier). I'm guessing that they use the Sampler State Pointer field in the message /header/, instead of the Sampler Index field in the message /descriptor/. On Haswell, that changed to be relative to Dynamic State Base Address instead of General State Base Address. Which probably helps. Still, that's probably going to be kind of miserable. I'll have to look into what they're doing. NAK on patch 2. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.
This causes us to advertise: - GL_MAX_TEXTURE_IMAGE_UNITS = 32 - GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS = 32 - GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS = 96 instead of the old values of 16, 16, and 48. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/brw_context.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) This is covered by Piglit's existing max-samplers test. (Thanks Marek!) diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h index 63dd4a0..5908659 100644 --- a/src/mesa/drivers/dri/i965/brw_context.h +++ b/src/mesa/drivers/dri/i965/brw_context.h @@ -650,7 +650,7 @@ struct brw_gs_prog_data }; /** Number of texture sampler units */ -#define BRW_MAX_TEX_UNIT 16 +#define BRW_MAX_TEX_UNIT 32 /** Max number of render targets in a shader */ #define BRW_MAX_DRAW_BUFFERS 8 -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.
Does this actually work for 16? Sampler messages' descriptor only has 4 bits for the sampler index, so it seems you'd silently lose the top bit and get the wrong sampler parameters. On Thu, Jan 16, 2014 at 8:08 AM, Kenneth Graunke kenn...@whitecape.org wrote: This causes us to advertise: - GL_MAX_TEXTURE_IMAGE_UNITS = 32 - GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS = 32 - GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS = 96 instead of the old values of 16, 16, and 48. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/brw_context.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) This is covered by Piglit's existing max-samplers test. (Thanks Marek!) diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h index 63dd4a0..5908659 100644 --- a/src/mesa/drivers/dri/i965/brw_context.h +++ b/src/mesa/drivers/dri/i965/brw_context.h @@ -650,7 +650,7 @@ struct brw_gs_prog_data }; /** Number of texture sampler units */ -#define BRW_MAX_TEX_UNIT 16 +#define BRW_MAX_TEX_UNIT 32 /** Max number of render targets in a shader */ #define BRW_MAX_DRAW_BUFFERS 8 -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.
On 01/15/2014 12:56 PM, Chris Forbes wrote: Does this actually work for 16? Sampler messages' descriptor only has 4 bits for the sampler index, so it seems you'd silently lose the top bit and get the wrong sampler parameters. Oh, wow. No...no, it can't possibly work then. (Apparently that Piglit test isn't sufficient...I just glanced at it...) It looks like the Intel Windows driver has bumped this to 32 on Haswell (but not earlier). I'm guessing that they use the Sampler State Pointer field in the message /header/, instead of the Sampler Index field in the message /descriptor/. On Haswell, that changed to be relative to Dynamic State Base Address instead of General State Base Address. Which probably helps. Still, that's probably going to be kind of miserable. I'll have to look into what they're doing. NAK on patch 2. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
