2021-01-06 05:06:10 +08:00
|
|
|
; RUN: llc -mtriple=amdgcn--amdpal -verify-machineinstrs < %s | FileCheck -check-prefix=GCN %s
|
|
|
|
; RUN: llc -mtriple=amdgcn--amdpal -mcpu=tonga -verify-machineinstrs < %s | FileCheck -check-prefix=GCN %s
|
|
|
|
; RUN: llc -mtriple=amdgcn--amdpal -mcpu=gfx900 -verify-machineinstrs < %s | FileCheck -check-prefix=GCN -enable-var-scope %s
|
[AMDGPU] For amdpal, widen interpolation mode workaround
Summary:
The interpolation mode workaround ensures that at least one
interpolation mode is enabled in PSInputAddr. It does not also check
PSInputEna on the basis that the user might enable bits in that
depending on run-time state.
However, for amdpal os type, the user does not enable some bits after
compilation based on run-time states; the register values being
generated here are the final ones set in the hardware. Therefore, apply
the workaround to PSInputAddr and PSInputEnable together. (The case
where a bit is set in PSInputAddr but not in PSInputEnable is where the
frontend set up an input arg for a particular interpolation mode, but
nothing uses that input arg. Really we should have an earlier pass that
removes such an arg.)
Reviewers: arsenm, nhaehnle, dstuttard
Subscribers: kzhuravl, wdng, yaxunl, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D37758
llvm-svn: 315591
2017-10-13 00:16:41 +08:00
|
|
|
|
|
|
|
; This pixel shader does not use the result of its interpolation, so it would
|
|
|
|
; end up with an interpolation mode set in PSAddr but not PSEnable. This test tests
|
|
|
|
; the workaround that ensures that an interpolation mode is also set in PSEnable.
|
|
|
|
; GCN-LABEL: {{^}}amdpal_psenable:
|
2020-10-23 17:21:03 +08:00
|
|
|
; GCN: .amdgpu_pal_metadata
|
|
|
|
; GCN-NEXT: ---
|
|
|
|
; GCN-NEXT: amdpal.pipelines:
|
|
|
|
; GCN-NEXT: - .hardware_stages:
|
|
|
|
; GCN-NEXT: .ps:
|
|
|
|
; GCN-NEXT: .entry_point: amdpal_psenable
|
|
|
|
; GCN-NEXT: .scratch_memory_size: 0
|
|
|
|
; GCN: .registers:
|
|
|
|
; GCN-NEXT: 0x2c0a (SPI_SHADER_PGM_RSRC1_PS):
|
|
|
|
; GCN-NEXT: 0x2c0b (SPI_SHADER_PGM_RSRC2_PS):
|
|
|
|
; GCN-NEXT: 0xa1b3 (SPI_PS_INPUT_ENA): 0x2
|
|
|
|
; GCN-NEXT: 0xa1b4 (SPI_PS_INPUT_ADDR): 0x2
|
|
|
|
; GCN-NEXT: ...
|
|
|
|
; GCN-NEXT: .end_amdgpu_pal_metadata
|
[AMDGPU] For amdpal, widen interpolation mode workaround
Summary:
The interpolation mode workaround ensures that at least one
interpolation mode is enabled in PSInputAddr. It does not also check
PSInputEna on the basis that the user might enable bits in that
depending on run-time state.
However, for amdpal os type, the user does not enable some bits after
compilation based on run-time states; the register values being
generated here are the final ones set in the hardware. Therefore, apply
the workaround to PSInputAddr and PSInputEnable together. (The case
where a bit is set in PSInputAddr but not in PSInputEnable is where the
frontend set up an input arg for a particular interpolation mode, but
nothing uses that input arg. Really we should have an earlier pass that
removes such an arg.)
Reviewers: arsenm, nhaehnle, dstuttard
Subscribers: kzhuravl, wdng, yaxunl, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D37758
llvm-svn: 315591
2017-10-13 00:16:41 +08:00
|
|
|
define amdgpu_ps void @amdpal_psenable(i32 inreg, i32 inreg, i32 inreg, i32 inreg %m0, <2 x float> %pos) #6 {
|
|
|
|
%inst23 = extractelement <2 x float> %pos, i32 0
|
|
|
|
%inst24 = extractelement <2 x float> %pos, i32 1
|
|
|
|
%inst25 = tail call float @llvm.amdgcn.interp.p1(float %inst23, i32 0, i32 0, i32 %m0)
|
|
|
|
%inst26 = tail call float @llvm.amdgcn.interp.p2(float %inst25, float %inst24, i32 0, i32 0, i32 %m0)
|
|
|
|
ret void
|
|
|
|
}
|
|
|
|
|
|
|
|
declare float @llvm.amdgcn.interp.p1(float, i32, i32, i32) #2
|
|
|
|
declare float @llvm.amdgcn.interp.p2(float, float, i32, i32, i32) #2
|
|
|
|
|
|
|
|
attributes #6 = { nounwind "InitialPSInputAddr"="2" }
|