Page MenuHomePhabricator

[OpenCL] Change sampler representation
Needs ReviewPublic

Authored by dmitry on Jan 3 2018, 3:15 AM.

Details

Summary

Change sampler encoding so that it's now a set of bit-flags and there must be exactly 3 of them set: one for each of parameters required by OpenCL specification (addressing mode, filter and coordinates normalisation). Thus there are no defaults and all modes must be specified explicitly and there isn't a combination of addressing mode flags that could produce another valid addressing mode.

Diff Detail

Event Timeline

dmitry created this revision.Jan 3 2018, 3:15 AM
svenvh added a subscriber: svenvh.Jan 5 2018, 9:17 AM
yaxunl added a comment.Jan 9 2018, 7:46 AM

What's the benefit of this change? Since this change will require all device libraries implementing __translate_sampler_initializer to change accordingly. We need a compelling reason.

What's the benefit of this change? Since this change will require all device libraries implementing __translate_sampler_initializer to change accordingly. We need a compelling reason.

I agree. The current layout doesn't prevent validation.

What's the benefit of this change? Since this change will require all device libraries implementing __translate_sampler_initializer to change accordingly. We need a compelling reason.

I agree. The current layout doesn't prevent validation.

I think the main issue is that this patch allows to detect problems when several values of the same type are mistakenly combined. I.e. if you look in test/SemaOpenCL/sampler_t.cl this allows to detect when addressing mode is set twice to different values:

constant sampler_t glb_smp5 = CLK_ADDRESS_CLAMP_TO_EDGE | CLK_ADDRESS_CLAMP ...

Even though it seems to be obvious in this example it might not always be the case. The code might be written using macros or even function calls to obtain the sampler mode. By giving each sampler type value a unique bit we are able to detect and diagnose such cases.

This will break all existing implementations and is not backwards compatible. Is this extra diagnosis really worthwhile? Are developers complaining?

This will break all existing implementations and is not backwards compatible. Is this extra diagnosis really worthwhile? Are developers complaining?

Ok. Do you envision it would be a big change to update though? It looks like a useful diagnostic improvement and also makes this a bit cleaner. But of course, if it causes large overhead, it would be undesirable.

@yaxunl there are two benefits of this change.

  1. As pointed by Anastasia. Currently, we have values of addressing mode flags so that they produce valid addressing mode if to combine some of them (see Anastasia's example). And the spec (https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/sampler_t.html) says addressing mode must be one of CLK_ADDRESS_REPEAT, CLK_ADDRESS_CLAMP_TO_EDGE, CLK_ADDRESS_CLAMP, CLK_ADDRESS_NONE. Though the spec doesn't require it, it's still better to diagnose if a developer specified multiple addressing modes.
  2. In current implementation filtering modes and normalized coordinates might be omitted when initializing samplers. The spec again says that these fields must be one of the predefined enums. Thus having defaults (i.e. constants of 0 values) allow a developer to omit some of the modes and write less portable code which is harder to debug.

So these 2 points are clearly technical benefits of this patch.

@yaxunl there are two benefits of this change.

  1. As pointed by Anastasia. Currently, we have values of addressing mode flags so that they produce valid addressing mode if to combine some of them (see Anastasia's example). And the spec (https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/sampler_t.html) says addressing mode must be one of CLK_ADDRESS_REPEAT, CLK_ADDRESS_CLAMP_TO_EDGE, CLK_ADDRESS_CLAMP, CLK_ADDRESS_NONE. Though the spec doesn't require it, it's still better to diagnose if a developer specified multiple addressing modes.
  2. In current implementation filtering modes and normalized coordinates might be omitted when initializing samplers. The spec again says that these fields must be one of the predefined enums. Thus having defaults (i.e. constants of 0 values) allow a developer to omit some of the modes and write less portable code which is harder to debug.

So these 2 points are clearly technical benefits of this patch.

Ping! @yaxunl, it would be nice to conclude how to proceed here. Do you still feel we don't have a convincing argument to go ahead with this change?

@yaxunl there are two benefits of this change.

  1. As pointed by Anastasia. Currently, we have values of addressing mode flags so that they produce valid addressing mode if to combine some of them (see Anastasia's example). And the spec (https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/sampler_t.html) says addressing mode must be one of CLK_ADDRESS_REPEAT, CLK_ADDRESS_CLAMP_TO_EDGE, CLK_ADDRESS_CLAMP, CLK_ADDRESS_NONE. Though the spec doesn't require it, it's still better to diagnose if a developer specified multiple addressing modes.
  2. In current implementation filtering modes and normalized coordinates might be omitted when initializing samplers. The spec again says that these fields must be one of the predefined enums. Thus having defaults (i.e. constants of 0 values) allow a developer to omit some of the modes and write less portable code which is harder to debug.

So these 2 points are clearly technical benefits of this patch.

Ping! @yaxunl, it would be nice to conclude how to proceed here. Do you still feel we don't have a convincing argument to go ahead with this change?

Sorry for the delay.

Both the old and new definitions can diagnose invalid sampler values. The advantage of the new definition is that

  1. it is able to detect certain invalid mixing of different modes of the same kind, e.g. CLK_ADDRESS_CLAMP_TO_EDGE | CLK_ADDRESS_CLAMP_ , whereas the old definition may fail to detect (not always, only for certain combinations).
  2. it forces user not to use 0 as initial value for sampler since 0 is no longer a valid sampler value. (I think this is not a significant advantage since if a user wants to use number instead of macro to initialize the sampler for some reason, they may continue doing that after this change).

The disadvantage is

  1. There is binary backward compatibility issue which may break the existing OpenCL applications: The applications may use hard coded sampler values, or store/load them to/from disk, or use LLVM binaries which assume old sampler value definitions. If OpenCL runtime suddenly switches to the new macro definition, these applications will break. To support the old applications, the runtime needs to detect the runtime version these applications compiled with and support the old sample definition, which increases the complexity of the OpenCL runtime.
  1. the new definition is less extendable. If new address mode is added, it is easy for the old definition to maintain binary backward compatibility since the old definition has room for new address mode. However for the new definition, it is hard to maintain binary backward compatibility and a clean definition at the same time. If the new bit is added at higher bits they are going to be separated from the other bits for address mode.

Probably we should seek opinions from more OpenCL platform/library developers since this change could be disruptive for them.

I believe there are 20 distinct samplers. I'd be more comfortable with this if you could arrange that __translate_sampler_initializer would be called with values in [0, 19] instead of [133, 322].

I believe there are 20 distinct samplers. I'd be more comfortable with this if you could arrange that __translate_sampler_initializer would be called with values in [0, 19] instead of [133, 322].

And, FWIW, after subtracting 16 from the current input to __translate_sampler_initializer, we get a number in the range [0, 25] which is close enough.

Anastasia added a comment.EditedJan 31 2018, 7:02 AM

whereas the old definition may fail to detect (not always, only for certain combinations).

For this reason I think it would be good to fix this. I don't think it's good to report errors inconsistently

  1. the new definition is less extendable. If new address mode is added, it is easy for the old definition to maintain binary backward compatibility since the old definition has room for new address mode. However for the new definition, it is hard to maintain binary backward compatibility and a clean definition at the same time. If the new bit is added at higher bits they are going to be separated from the other bits for address mode.

Probably we should seek opinions from more OpenCL platform/library developers since this change could be disruptive for them.

Sure, let's hope some over developers can jump in. As for sampler modes I am not sure how much it is going to change in the future OpenCL versions. And as for binary compatibility I think this is a valid point, however it is solvable (by maintaining binary versions). I think we won't be able to do many interesting compiler refactoring tasks if we are to keep binary format unchanged.... It would be very pity to restrict us on that. Perhaps we should think of the solution to that overall long term.