New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
depth-clip-control feature is unimplemented #10288
depth-clip-control feature is unimplemented #10288
Conversation
EWS run on previous version of this PR (hash 7d37024) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -43,14 +43,14 @@ class PipelineLayout; | |||
class RenderPipeline : public WGPURenderPipelineImpl, public RefCounted<RenderPipeline> { | |||
WTF_MAKE_FAST_ALLOCATED; | |||
public: | |||
static Ref<RenderPipeline> create(id<MTLRenderPipelineState> renderPipelineState, MTLPrimitiveType primitiveType, std::optional<MTLIndexType> indexType, MTLWinding frontFace, MTLCullMode cullMode, MTLDepthStencilDescriptor *depthStencilDescriptor, MTLRenderPipelineReflection *reflection, Device& device) | |||
static Ref<RenderPipeline> create(id<MTLRenderPipelineState> renderPipelineState, MTLPrimitiveType primitiveType, std::optional<MTLIndexType> indexType, MTLWinding frontFace, MTLCullMode cullMode, MTLDepthClipMode depthClipMode, MTLDepthStencilDescriptor *depthStencilDescriptor, MTLRenderPipelineReflection *reflection, Device& device) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it preferable to keep adding arguments to create calls or should we pass arguments via a descriptor struct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if RenderPipeline::create
was more widely used I would say descriptor struct for sure but let me remove one of the overloads since I think that is not needed
b770e7b
to
b8a5d94
Compare
EWS run on previous version of this PR (hash b8a5d94) |
@@ -474,7 +481,7 @@ static auto convertToBacking(const RenderPipelineDescriptor& descriptor, Convert | |||
static_cast<uint32_t>(backingBuffers.size()), | |||
backingBuffers.data(), | |||
}, { | |||
nullptr, | |||
descriptor.primitive && descriptor.primitive->unclippedDepth ? &depthClipControl.chain : nullptr, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should only do this if the clip control feature is enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! I just discovered WebGPU requires opt-in for features
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will add this validation to Device::createRenderPipeline
so we return an invalid pipeline when the feature is not enabled and unclippedDepth == true
which is what I believe the specification requires
static Ref<RenderPipeline> create(id<MTLRenderPipelineState> renderPipelineState, MTLPrimitiveType primitiveType, std::optional<MTLIndexType> indexType, MTLWinding frontFace, MTLCullMode cullMode, MTLDepthStencilDescriptor *depthStencilDescriptor, MTLRenderPipelineReflection *reflection, Device& device) | ||
static Ref<RenderPipeline> create(id<MTLRenderPipelineState> renderPipelineState, MTLPrimitiveType primitiveType, std::optional<MTLIndexType> indexType, MTLWinding frontFace, MTLCullMode cullMode, MTLDepthClipMode depthClipMode, MTLDepthStencilDescriptor *depthStencilDescriptor, MTLRenderPipelineReflection *reflection, const PipelineLayout *pipelineLayout, Device& device) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is getting pretty unwieldy, can we batch these together in a struct or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could pass the WGPURenderPipelineDescriptor
and let the constructor do the unpacking. What do you think of that idea?
return RenderPipeline::createInvalid(*this); | ||
MTLDepthClipMode mtlDepthClipMode = MTLDepthClipModeClip; | ||
if (descriptor.primitive.nextInChain) { | ||
if (descriptor.primitive.nextInChain->sType != WGPUSType_PrimitiveDepthClipControl) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|| descriptor.primitive.nextInChain->nextInChain
const PipelineLayout* pipelineLayout = nullptr; | ||
if (descriptor.layout) { | ||
if (auto& layout = WebGPU::fromAPI(descriptor.layout); layout.numberOfBindGroupLayouts()) | ||
pipelineLayout = &layout; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems unrelated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is to avoid two ::create
functions with almost identical parameters
@@ -182,7 +181,8 @@ async function helloCube() { | |||
fragment: fragmentStageDescriptor, | |||
primitive: { | |||
topology: "triangle-list", | |||
cullMode: "back" | |||
cullMode: "back", | |||
unclippedDepth: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we have to enable the feature at device creation time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that is correct. I will fix that
if (depthClipControl->unclippedDepth) | ||
mtlDepthClipMode = MTLDepthClipModeClamp; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have to do any workarounds or anything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The extent of the workaround is the WGSL compiler should clamp fragDepth, when written, to the viewport z-bounds. I will file a bug for this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
b8a5d94
to
664a490
Compare
EWS run on current version of this PR (hash 664a490)
|
https://bugs.webkit.org/show_bug.cgi?id=251664 <radar://104992830> Reviewed by Myles C. Maxfield. Implement depth clip control which controls if fragments with depth values outside of [0, 1] are clipped or not. * Source/WebCore/PAL/pal/graphics/WebGPU/Impl/WebGPUDeviceImpl.cpp: (PAL::WebGPU::convertToBacking): * Source/WebGPU/WebGPU/HardwareCapabilities.mm: (WebGPU::baseFeatures): All devices support depth clamping. * Source/WebGPU/WebGPU/RenderPassEncoder.mm: (WebGPU::RenderPassEncoder::setPipeline): (WebGPU::RenderPassEncoder::setStencilReference): * Source/WebGPU/WebGPU/RenderPipeline.h: (WebGPU::RenderPipeline::create): (WebGPU::RenderPipeline::depthClipMode const): * Source/WebGPU/WebGPU/RenderPipeline.mm: (WebGPU::Device::createRenderPipeline): (WebGPU::RenderPipeline::RenderPipeline): Pass the feature through to the command encoder. * Websites/webkit.org/demos/webgpu/scripts/two-cubes.js: Update two-cubes to illustrate this feature. Canonical link: https://commits.webkit.org/260723@main
664a490
to
1a696df
Compare
Committed 260723@main (1a696df): https://commits.webkit.org/260723@main Reviewed commits have been landed. Closing PR #10288 and removing active labels. |
1a696df
664a490