다이렉트X - 페이지 3

새 코멘트
 
Rorschach :

정말 감사합니다!

이중으로 계산합니까? 그런 다음 결과가 특히 인상적입니다.

부분 참고. 실제로 한 곳에서는 double 대신 float 가 있었습니다. 

D = fast_length(p);

더블이 되려면 다음과 같이 수정해야 합니다. 

D = length(p);

*buf 인수에 uint 대신 uchar4 를 사용하여 마지막 줄(XRGB 매크로와 유사)을 제거할 수도 있습니다. 다음과 같이 시도하십시오. 

__kernel void Func( int N, __global double *XP, __global double *YP, __global uchar *h, __global uchar4 *buf)
{
   size_t X = get_global_id( 0 );
   size_t Width = get_global_size( 0 );
   size_t Y = get_global_id( 1 );
   
   float2 p;
   double D= 0 ,S1= 0 ,S2= 0 ;
   
   for ( int w= 0 ;w<N;w++){ 
      p.x = XP[w]-X;
      p.y = YP[w]-Y;
      D = length(p);
      S2+=D;
       if (w<N/ 2 )
         S1+=D;
   }   
   //
   double d=S1/S2;
   buf[Y*Width+X] = (uchar4)( 0xFF ,h[( int )(d* 11520 )],h[( int )(d* 17920 )],h[( int )(d* 6400 )]);
}
 
Serhii Shevchuk :

정말 인상적입니다! FPS는 셰이더보다 1.5배 높습니다.

감사합니다. 코드가 작동하고 성능이 떨어지지 않고 마지막 줄에서만 알파 채널이 끝으로 이동되었습니다. 

buf[Y*Width+X] = (uchar4)(h[( int )(d* 11520 )],h[( int )(d* 17920 )],h[( int )(d* 6400 )], 0xFF );
 
Rorschach :

정말 인상적입니다! FPS는 셰이더보다 1.5배 높습니다.

감사합니다. 코드가 작동하고 성능이 떨어지지 않고 마지막 줄에서만 알파 채널이 끝으로 이동되었습니다.

이 구현에서 성능은 센터 수(N)에 크게 의존합니다. 좋은 방법은 커널 에서 순환을 제거해야 하지만 S1과 S2는 정수가 되어야 합니다. 그들의 가치가 얼마나 널리 퍼져 있는지 볼 필요가 있습니다. 아마도 많은 죄가없는 것으로 판명 될 것입니다. 그런 다음 사이클을 3차원으로 변환할 수 있습니다. 그러면 이론적으로 N 값이 클수록 성능이 향상됩니다.

N = 128의 풀 HD 모니터에서 HD 7950에서 80-90fps를 얻습니다.

 
Serhii Shevchuk :

이 구현에서 성능은 센터 수(N)에 크게 의존합니다. 좋은 방법은 커널 에서 순환을 제거해야 하지만 S1과 S2는 정수가 되어야 합니다. 그들의 가치가 얼마나 널리 퍼져 있는지 볼 필요가 있습니다. 아마도 많은 죄가없는 것으로 판명 될 것입니다. 그런 다음 사이클을 3차원으로 변환할 수 있습니다. 그러면 이론적으로 N 값이 클수록 성능이 향상됩니다.

N = 128의 풀 HD 모니터에서 HD 7950에서 80-90fps를 얻습니다.

내 750ti 11fps에서. 카드 사양을 찾았습니다.

GPU
 FP32 GFLOPS
 FP64 GFLOPS 비율
라데온 HD 7950 2867 717 FP64 = 1/4 FP32
지포스 GTX 750 Ti 1388 43 FP64 = 1/32 FP32

논리적으로 float로 전환하면 fps가 amd에서 4배, nvidia에서 한 번에 32배 증가할 수 있습니다.

 

OCL 버전을 복사했습니다. 나는 결과에 충격을 받았다. 1600개 센터에서는 영상의 85% 이상을 로드할 수 없었습니다.

h 사전 계산을 사용한 최적화는 효과가 없지만 그대로 남습니다. 모든 계산은 부동 소수점 형식이므로 double을 사용할 이유가 없습니다. 모든 함수는 여전히 float를 반환합니다.

파일:
pixel.zip  1 kb
Swirl2_OCL_mod.mq5  14 kb
 

몇 가지 결론.

1) 사전 계산 h는 영향을 미치지 않았습니다.

2) 떼면 차이를 못느끼겠음 

S1+=D*(i< 0.5 f*N);
//if (i<N* 0.5 f) S1+=D;

3) 너무 느림

 for ( int i= 0 ;i<N;i++)
  {XP[i]= ( 1 .f- sin (j/iArr[ 2 *i  ].w))*wh.x* 0.5 f;
   YP[i]= ( 1 .f- cos (j/iArr[ 2 *i+ 1 ].w))*wh.y* 0.5 f;
  }
float S1= 0 .f,S2= 0 .f;
for ( int i= 0 ;i<N;i++)
  {float2 p;
   p.x=XP[i]-Pos.x;
   p.y=YP[i]-Pos.y;
   ...
  }

그보다

 float S1= 0 .f,S2= 0 .f;
for ( int i= 0 ;i<N;i++)
  {float2 p;
   p.x=( 1 .f- sin (j/iArr[ 2 *i  ].w))*wh.x* 0.5 f-Pos.x;
   p.y=( 1 .f- cos (j/iArr[ 2 *i+ 1 ].w))*wh.y* 0.5 f-Pos.y;
   ...
  }

겉보기에...

4) 퍼센트, 즉 스캘핑 주문 등에 대해 언로드할 수 없습니다. 당신은 잊을 수 있습니다.

 
Rorschach :

몇 가지 결론.

1) 사전 계산 h는 영향을 미치지 않았습니다.

2) 떼면 차이를 못느끼겠음

3) 너무 느림

그보다

겉보기에...

4) 스캘핑 주문 등에 대한 퍼센트를 언로드할 수 없습니다. 당신은 잊을 수 있습니다.

MT5에서 스캘핑 주문서는 OCL 없이 하나의 스레드에서 쉽게 작동하고 프로세서에 과부하가 걸리지 않습니다. 물론 이것이 필요하지 않다는 의미는 아닙니다. 그냥 메모입니다.

유리를 만들 때 CCanvas 클래스 를 사용하면 작업 부하가 유리 면적에 비례합니다. 저것들. - 유리창이 클수록, 전체 캔버스가 분리되지 않고 변경된 부분이 다시 그려지기 때문에 부하가 높아집니다. 그러나 주문서 셀을 독립 요소로 전환하면 나머지 캔버스 영역과 독립적으로 업데이트할 수 있으므로 다시 그리는 시간과 이로 인한 CPU 부하를 크게 줄일 수 있습니다.

 
Реter Konow :

MT5에서 스캘핑 주문서는 OCL 없이 하나의 스레드에서 쉽게 작동하고 프로세서에 과부하가 걸리지 않습니다. 물론 이것이 필요하지 않다는 의미는 아닙니다. 그냥 메모입니다.

유리를 만들 때 CCanvas 클래스를 사용하면 작업 부하가 유리 면적에 비례합니다. 저것들. - 유리창이 클수록, 전체 캔버스가 분리되지 않고 변경된 부분이 다시 그려지기 때문에 부하가 높아집니다. 그러나 주문서 셀을 독립 요소로 전환하면 나머지 캔버스 영역과 독립적으로 업데이트할 수 있으므로 다시 그리는 시간과 이로 인한 프로세서 부하를 크게 줄일 수 있습니다.

4번 항목이 의심스럽습니다. Remnant3D 예제에서는 백분율이 거의 로드되지 않습니다.

 
Rorschach :

4번 항목이 의심스럽습니다. Remnant3D 예제에서는 백분율이 거의 로드되지 않습니다.

확인되었습니다. 값이 변경된 개별 셀을 다시 그리면 주문서의 일반적인 역학으로 MT5의 백분율이 거의로드되지 않습니다.

반대로 각 들어오는 값의 이벤트에 캔버스의 전체 영역이 그려지면 프로세서는 매우 스트레스를 받게 됩니다.

차이점은 픽셀 배열에서 다시 초기화된 값의 수입니다. 개별 영역의 선택적 업데이트가 필요하며 로드에는 문제가 없습니다.

 
Реter Konow :

확인되었습니다. 값이 변경된 개별 셀을 다시 그리면 주문서의 일반적인 역학으로 MT5의 백분율이 거의로드되지 않습니다.

반대로 각 들어오는 값의 이벤트에 캔버스의 전체 영역이 그려지면 프로세서는 매우 스트레스를 받게 됩니다.

차이점은 픽셀 배열에서 다시 초기화된 값의 수입니다. 개별 영역의 선택적 업데이트가 필요하며 로드에는 문제가 없습니다.

Remnant3D에서 캔버스가 전체 화면이고 백분율이 로드되지 않는다는 것은 농담입니다.

12345678910...12
새 코멘트