Pixi.js: gl 매트릭스로 간주됩니까?

1) SIMD가 죽었습니다. https://github.com/rwaldron/tc39-notes/blob/a66df6740eec3358d5e24f81817db99d6ee41401/es8/2017-03/mar-21.md#10if -simdjs-status-update

2) 단순한 6개의 필드 "a,b,c,d,tx,ty"는 Float32Array(9) 행렬보다 훨씬 더 나은 성능을 보입니다. 테스트에 대한 링크를 제공할 수 없지만 나와 @GoodBoyDigital 모두 이미 통합을 시도했습니다.

3) JS는 큰 좌표로 작동하는 앱에 중요한 배정밀도를 수행합니다. 그래픽 및 스프라이트에 대한 "프로젝션 x 변환"은 JS 측에 있는 것이 좋습니다.

나는 v5에서 Float32Array(9)를 사용하고 있는데, 이것은 내 jsperf 테스트에서 동일한 성능은 아닐지라도 유사했으며 우리가 toArray 및 transpose 작업을 수행할 필요가 없도록 합니다.

https://github.com/pixijs/pixi.js/blob/455c059e8d155c1d9a05fc2ece2c02b3bdf8bf84/plugins/core/src/math/Matrix.js

gl-matrix 는 SIMD(Ivan이 언급했듯이 죽은 사양임)가 있기 때문에 유용하지만 구현 시에도 단점이 있습니다. 우리는 3x3 행렬( Float32Array(9) )이 GPU에 닿기를 원하지만 계산 시간을 절약하기 위해 2D 행렬인 것처럼 연산을 수행합니다. gl-matrix 에는 이에 대한 좋은 메커니즘이 없습니다.

v5 버전은 GPU에 직접 업로드할 수 있는 스토리지를 사용하고 관심 있는 2D 부분에서만 작동합니다. 또한 SharedArrayBuffers 및 웹 작업자에 더 많은 작업을 수행할 수 있는 기타 최적화를 사용할 수 있도록 설정합니다. 우리는 우리가 그것으로 얼마나 멀리 갈 수 있는지 볼 것입니다.

@englercj 일관성을 유지하기 위해 Math.fround를 여러 곳에서 사용해야 할 것 같습니다. perf Float64Array를 사용해보십시오.

Float64Array로 만들 수 있지만 업로드를 위해 단정밀도로 크기를 줄여야 합니다. 또한 현재 GPU에 업로드할 때 float32를 사용하고 있음을 기억하십시오. 그래서 우리는 수학을 이중으로 한 다음 단일로 자릅니다. 이 모든 작업을 한 번에 수행하는 것보다 더 정확할 수 있지만 업로드하는 데이터 유형과 일관성을 유지하려고 합니다. 불행히도 이것은 GL 4.0까지는 단정밀도를 의미하고 WebGL 2는 GL ES 3.0에 불과합니다.

매트릭스 업로드는 결코 우리의 병목 현상이 아니었습니다. 우리는 그 위치에서 "uniform3fv"를 사용합니다. 이것은 간단한 작업이 아니며 drawCall이 뒤따르고 대부분의 경우 큰 버퍼 업로드입니다. Heavy pixi 앱은 프레임당 약 400개의 드로콜만 수행합니다.

큰 좌표에 대한 사용자의 문제가 발생한 후에는 업로드할 때까지 모든 것을 배정밀도로 저장하는 것을 선호합니다.

또한 "a,b,c,d,tx,ty" 표기법은 "0,1,3,4,6,7"보다 쓰기와 읽기가 더 쉽습니다. 척추에도 사용되며 그 위에 매우 정교한 변환이 있습니다. 행렬로 전환하면 나중에 코드를 확인하기가 쉽지 않을 것입니다. 어떤 사람들에게는 행렬 연산을 상상하기 어렵지만 저는 쉽게 읽습니다.

UPD. 나는 또한 이것이 행렬을 변환하는 것보다 우리에게 더 도움이 될 것이라고 생각합니다: https://github.com/gameofbombs/gobi/blob/master/src/core/math/FlatTransform2d.ts , 이는 "Flat" 변환이며 필요한 모든 필드를 포함합니다. 행렬의 계산을 위해.

UPD2. 그러나 3d 변환의 경우 Float32Array(16)가 더 좋으며 이에 대해 언급하지 않겠습니다.

내 투표는 최고의 성능을 제공하는 하나에 이동합니다. 마지막으로 배열을 통해 객체를 사용하여 확인한 것이 더 빠릅니다. 그것이 여전히 사실인지 100% 확신할 수는 없지만, 아마도 바뀌었을 것입니다!

3d의 경우 주로 GPU에 항목이 많이 업로드되기 때문에 gl-matrix 스타일을 선호합니다! Pixi에서는 일반적으로 그렇지 않습니다. 대부분의 조작은 js 랜드(예: 스프라이트 배처)에서 발생합니다.

https://jsperf.com/obj-vs-array-view-access/1

여기 내가 한 테스트가 있습니다. 개체 방법 느린 일반 배열보다 둘, Float32Array보다 uniform3fv 는 일반 Array 개체를 허용하므로 해당 개체로 전환해야 합니다.

편집: Array 결과가 우연이었던 것 같습니다. 재현할 수 없습니까?

내 투표는 최고의 성능을 제공하는 하나에 이동합니다.
마지막으로 배열을 통해 객체를 사용하여 확인한 것이 더 빠릅니다.

매우 흥미롭습니다. 객체 의미 체계가 크게 제거될 수 있다는 것을 알고 있는 기본 vm이 여러 최적화를 수행할 수 있어야 하기 때문에 객체가 순수한 숫자 배열보다 빠를 것이라는 것은 직관적이지 않은 것 같습니다. 개체가 더 빠를 수 있는 _이유_에 대한 아이디어가 있는지 궁금합니다.

내 구성 요소의 관련 결과(i7, Windows 10):

크롬 59:

Firefox 54.0.1(32비트):

마이크로소프트 엣지 40.15063.0.0:

Array 가 더 빨라진 내 크롬 결과는 우연이었던 것 같습니다. 그것이 무엇인지 확실하지 않지만 지금은 재현할 수 없습니다. 약 50M ops/s이지만 이전에 한 번 실행했을 때 500M ops/s였습니다. 기이 한...

어느 쪽이든 Float32Array 멤버는 모든 브라우저에서 일관되게 동일한 속도 또는 객체보다 빠릅니다. 이것이 내가 전환한 이유입니다. 이전과 같은 속도(또는 더 빠름)이지만 이제 업로드를 위해 배열을 바꾸거나 채우는 것을 피합니다.

Float64로도 그렇게 할 수 있습니까? :)

저는 드로콜당 하나 이상의 매트릭스 작업보다 코드 품질에 관심이 많습니다.

또한, 우리는 invert를 많이 사용하지 않습니다. updateTransform()이 우리의 문제입니다.

저는 드로콜당 하나 이상의 매트릭스 작업보다 코드 품질에 관심이 많습니다.

Float64Array는 어떻게 더 높은 코드 품질을 제공합니까? 나는 우리가 더 많은 정밀도를 얻는다는 것을 이해하지만, 어쨌든 단정밀도로 줄일 때 그것이 왜 그렇게 중요한지 알 수 없습니다.

또한, 우리는 invert를 많이 사용하지 않습니다. updateTransform()이 우리의 문제입니다.

이것은 데이터 저장소의 읽기/쓰기를 벤치마킹하는 것으로, 그 사이의 값에 대해 수행되는 작업은 관련이 없습니다.

저는 드로콜당 하나 이상의 매트릭스 작업보다 코드 품질에 관심이 많습니다.

저도 이에 동의합니다. 배열 기반 행렬, 점 및 벡터에 대한 "표준화"는 실제로 성능보다 코드 품질 향상에 더 가깝습니다... 인기 있는 js 행렬/벡터 라이브러리의 재사용 및 인기 있는 렌더링 모듈과의 더 많은 상호 운용성을 고려할 것입니다. 큰 코드 품질 승리가 될 것입니다.

이것은 데이터 저장소의 읽기/쓰기를 벤치마킹하고,
관련 없는 값 사이에 수행된 작업입니다.

나는 당신이 모두 옳다고 생각합니다. 이것은 데이터 스토리지 읽기/쓰기의 일반적인 벤치마킹입니다. 그러나 Ivan은 정말 좋은 점을 가지고 있습니다. updateTransform() 가 압도적인 연산이라면, 그것을 보는 것이 매력적일 것입니다.

나는 일반적으로 마이크로 벤치마크에 대해 걱정합니다. 이러한 정적 데이터 세트를 사용하면 이러한 테스트에서 자바스크립트 VM의 컴파일러 최적화를 실수로 활용하게 되는지 궁금합니다. 실제 테스트를 실행하는 것이 훨씬 더 계몽적일 것입니다(설정에 더 많은 작업이 필요함).

저도 이에 동의합니다. 배열 기반 행렬, 점 및 벡터에 대한 "표준화"는 실제로 성능보다 코드 품질 향상에 더 가깝습니다... 인기 있는 js 행렬/벡터 라이브러리의 재사용 및 인기 있는 렌더링 모듈과의 더 많은 상호 운용성을 고려할 것입니다. 큰 코드 품질 승리가 될 것입니다.

저는 "(a,b),(c,d),(tx,ty)" 배정밀도 행렬에 대해 업로드를 위해 float32array로 변환하고 "posX,posY,pivotX, pivotY,scaleX,scaleY, 전단X,전단Y,로Z". 어쨌든 내 포크에서 사용할 것이지만 마스터 pixi에서도 매트릭스 배열을 다루지 않는 것을 선호합니다. 그게 내 기준이야.

나는 또한 사람들이 js에서 vec 수학에 하나 또는 두 개의 표준을 사용하도록 만드는 것이 가능한지 의심스럽습니다.

Float64Array는 어떻게 더 높은 코드 품질을 제공합니까? 나는 우리가 더 많은 정밀도를 얻는다는 것을 이해하지만, 어쨌든 단정밀도로 줄일 때 그것이 왜 그렇게 중요한지 알 수 없습니다.

updateTransform에서 스프라이트 변환(스크롤용)으로 카메라 변환을 곱합니다. 결과는 작을 때만 화면에 나타나므로 결국 숫자는 적지만 스프라이트 위치와 카메라 위치 모두 클 수 있습니다. 사용자 측 솔루션:

1) 그의 편에서 모든 것을 계산하십시오. PIXI는 상대적으로 작은 좌표만 처리합니다.
2) 세계를 큰 좌표로 덩어리로 나누고 스프라이트는 상대적으로 작은 좌표를 갖지만 하위 픽셀 카메라에서는 작동하지 않습니다 => 카메라도 크고 작은 좌표가 필요합니다.

큰 프로젝트의 경우 사용자가 자신의 편에 서도록 하는 것은 괜찮지만 작은 프로젝트의 경우 한 번 더 골치 아픈 일입니다.

나는 또한 사람들이 js에서 vec 수학에 하나 또는 두 개의 표준을 사용하도록 만드는 것이 가능한지 의심스럽습니다.

무슨 말인지 이해가 안되는데 자세히 설명해주실 수 있나요?

무슨 말인지 이해가 안되는데 자세히 설명해주실 수 있나요?

할 수 없어, 나한테는 너무해.

저수준 최적화에서 서로 다른 경험을 가진 사람들이 있습니다. 및 언어 구성, DSL-s. 우리는 어떤 수준에서 우리 모두를 만족시키는 표준이 필요합니다.

지난 2년 동안 저는 서로 다른 변환을 사용하여 두 개의 pixi(v3 및 v4용) 포크를 만들었습니다. 저는 자체 고급 변환이 있는 "pixi-spine"을 다루고 있고 세 번째 포크를 만들고 있습니다. "과거 ivan"의 관점에서 보면 배열이 가장 단순하고 "gl-matrix"가 있기 때문에 가장 좋습니다.

나는 64비트를 유지하는 것이 중요하다는 @ivanpopelyshev의 말에 동의합니다. 각 프레임에 버퍼를 생성하고 복사하지 않고 효율적으로 이를 수행하는 방법을 알아 내려고 노력하고 있습니다.

Float64Array로 저장하고 업로드할 때 Float32Array로 복사할 수도 있습니다. 최소한 웹 작업자에게/에서 복사하기 더 쉬워야 하는 스토리지 백업으로 형식화된 배열을 사용할 수 있습니다.

Float64Array 그렇다면 (0,1), (3,4), (6,7)을 X,Y,translate로 사용하는 것을 기억해야 합니다.

모든 흥미로운 것들, 저는 우리가 제안한 솔루션을 실제 pixi 시나리오에서 벤치마킹하기를 원합니다. 예를 들어 bunnymark와 같은 것입니다.

이 분야에 대한 제 경험은 저와 @ivanpopelyshev가 마지막으로 bunny mark를 위해 gl-matrix로 전환했을 때 상당히 느리게 실행되었음을 발견했습니다(3분의 1 더 느림!).

그것은 조금 전의 일이었고 여기서 내가 틀렸으면 정말 좋았을 것입니다!
속도 차이가 이제 무시할 수 있다면 위에서 제안한 경로가 에이스가 될 것이라고 생각합니다.

Pixi is SPEEED :P 모든 솔루션을 완전히 커밋하기 전에 테스트해야 합니다.

여전히 Float64Array의 벤치마크가 필요합니다. 이 구현은 저에게 적합하지만 개인적으로 포크에서 오래된 매트릭스를 사용할 것입니다. 또한 호환성을 위해 속성을 추가하는 것을 잊지 마십시오.

한 가지 더: @mreinstein , 내가 기억하는 표준 중 하나는 paper.js 전용 언어인 PaperScript가 언어에 직접 포인트 연산을 추가한다는 것입니다. JS에 더 많은 구문 설탕이 있다면 우리도 그런 것을 사용할 것입니다.

re: 이 업데이트된 bunnymark에 대해 제가 도울 수 있는 것이 있습니까? 이 시간을 기부하게 되어 기쁩니다.

나는 여기에서 일어나는 일을 따라가는 데 매우 관심이 있습니다. 결과에 관계없이. 어레이 기반 항목이 여전히 훨씬 더 느리다면 그 뒤에 있는 _이유_가 정말 궁금합니다.

다시 주목해야 할 사항: 성능 테스트...크롬의 v8은 최근(v59에서) 터보팬이라는 v8에 대한 몇 가지 극적인 변경 사항을 발표했습니다. 상당한 성능 향상이 있을 것으로 예상됩니다.

https://v8project.blogspot.com/2017/05/launching-ignition-and-turbofan.html

터보팬이 존재하기 이전 버전에서 현재와 비교하여 업데이트된 bunnymark를 실행하는 것은 흥미로울 수 있습니다.

@GoodBoyDigital 나는

https://jsperf.com/obj-vs-array-view-access/1

Edge에서만 개체 속도가 Float64Array와 일치/초과하고 실제로 가깝습니다.

나는 이것을 내 환경에서 테스트했고 비슷한 결과를 얻었습니다 ... 도대체 무엇입니까?! Float64 배열 읽기/쓰기가 동등한 Float32 배열 작업보다 훨씬 더 빠른 이유는 무엇입니까? 마음에 오는 유일한 것은 64비트 부동 소수점이 단어 경계에 정렬된다는 것뿐입니까? 나는 당황한다.

제안에 감사드립니다 @mreinstein ! 당신이 확실히 냉담한 사실로 전체 논쟁을 잠재울 수 있는 몇 가지 성능 테스트로 우리를 도울 수 있다면!

가장 좋은 방법은 pixi를 분기한 다음 변환을 gl-matrix 또는 @englercj 매트릭스 클래스로

그런 다음 수정된 버전이 있으면 여기에서 성능을 테스트할 수 있습니다. https://pixijs.github.io/bunny-mark/
다른 배열 유형으로 엉망이 될 수 있습니다.

@englercj 멋진 친구입니다! 이러한 결과를 확실히 확인하는 것은 고무적입니다. v5 버전은 버니마크를 돌릴 수 있는 상태에 가깝습니까?

@mreinstein 그냥 직감, 64비트 -> 32비트에서 변환과 관련이 있다고 생각합니다.
js의 숫자가 64비트 맞나요?

@GoodBoyDigital 아마도 당신이 옳다고 생각합니다. 내 친구 부인에게 의지합니다. 구글, 나는 이것을 우연히 발견했다 :

https://stackoverflow.com/questions/15823021/when-to-use-float32array-instead-of-array-in-javascript

최고 등급의 답변(현재 44표)은 합리적이고 적절해 보입니다.

몇 가지 성능 테스트를 도와줄 수 있다면

알겠습니다. 도와드리겠습니다. :)

가장 좋은 것은 픽시를 포크하는 것입니다.

@GoodBoyDigital @englercj 이 시점에서 가장 좋은 분기점은 무엇입니까?

그런 다음 변환을 gl-matrix 또는 @englercj 매트릭스 클래스로 교체하십시오.
이 예에서는 전체 엔진이 아니라 스프라이트 배치도 작동하게 만들기만 하면 됩니다!

이에 대해 조금 더 자세히 설명해 주시겠습니까? 성능 벤치를 실행하기 위해 전체 엔진을 gl-matrix로 변환하고 싶지 않습니다... https://github.com/pixijs/bunny-mark에 sprite 배치 항목이 보이지 않습니다. 토끼가 추가되는 루트 요소로서의 PIXI.Container. 내가 pixi.container, pixi.sprite로 시작하고 거기에서 거꾸로 의존성 트리 위로 작업하여 변환 항목을 교체해야 하는 모든 위치를 찾아야 한다는 말씀이신가요? 동의하지 않는다는 것이 아니라 불필요한 작업을 최소화하기 위한 전략이 올바른지 확인하고 싶을 뿐입니다.

updateTransform에는 내부에 두 가지 행렬 연산이 있습니다.

1. 위치, 피벗, 스케일, 회전의 구성 - 개선할 수 없습니다.
2. 부모 행렬에 의한 곱셈 - 향상될 수 있습니다.

Float64Array가 지원하는 오래된 "a,b,c,d,tx,ty" 소품으로 행렬 클래스를 만들고 updateTransform을 다시 작성하는 것이 좋습니다. 또한 @mreinstein 은 핵심에

그래서 그는 가지에 접근할 수 있고 농장을 지을 수 있습니다.

모든 사람이 액세스할 수 있으며 fork + PR이 이 모든 작업을 수행합니다.

나는 여러분이 버니 마크에서 어떤 종류의 결과를 얻었는지 궁금합니다. 기본 100k 버니를 사용하여 크롬에서 다양한 분기(개발, 릴리스, 기타)를 시도할 때 일관되게 10-16fps를 얻습니다. 8.75초 이상 실행되는 코드에 대한 성능 분석 수행:

거의 모든 시간을 자바스크립트 호출에 소비합니다.

자바스크립트에서 보낸 이 시간 중 가장 많은 부분을 차지하는 시간은 실제로 Sprite.calculateVertices() 입니다. TransformStatic.updateTransform() 지출보다 4배 더 많음

파이어폭스에서는 프레임 속도가 약 2배이지만 소요 시간은 비슷합니다. calculateVertices() 는 두 브라우저 모두에서 많은 시간을 차지합니다. 예상되는 일입니까? bunnymark 실행에서 비슷한 결과를 얻고 있습니까?

이것은 토끼에게 예상됩니다. 그리고 우리가 말하는 행렬 연산은 곱셈을 위한 upateTransform()과 호출당 한 번만 플러시()하는 두 곳에서 수행됩니다. 대규모로 해도 상관없습니다.

혼란스러워요. :( 그 벤치마크의 성능을 어떻게 알 수 있습니까? 나는 그것이 대부분 달성된 순수한 fps를 기반으로 한다는 인상을 받았습니다. 그것이 사실이라면, 내 프레임 속도는 정점 계산에 의해 _심각하게_ 조절되고 있습니다. 내가 붙여넣은 첫 번째 다이어그램을 보면 위에서 렌더링은 총 프레임 시간의 아주 작은 부분이며 정점 및 변환 업데이트는 총 프레임 시간을 압도합니다.

그것이 거짓이고 fps가 내 pixi 빌드의 성능에 대한 측정이 아닌 경우 주어진 빌드를 측정하기 위해 어떤 기준을 사용합니까?

GPU 측(표시되지 않음)의 CPU 또는 CPU에서 조절될 수 있습니다.

FPS가 60보다 훨씬 낮지만 "유휴"가 큰 경우 GPU입니다.

유휴 상태가 작으면 CPU입니다.

computeVertices에는 내부에 행렬 연산이 있습니다. 네 모서리를 행렬로 곱하기만 하면 됩니다.

TS 포크에 대한 작은 아이디어: 행렬 유형에 대한 속성을 인라인하는 변환을 추가합니다. TS에는 아직 그런 종류의 변형이 없다는 것이 부끄러운 일입니다 :(

행렬 변수에 주석을 달 수 있는 방법을 찾으면 babel에서도 가능하다고 생각합니다.

나는 더 이상 무슨 일이 일어나고 있는지 이해할 수 없습니다.

염두에 두어야 할 사항: 이 벤치마크의 목표는 처음에 개체와 gl-매트릭스를 사용하면 예상대로 성능이 크게 저하되는지 확인하는 것이었습니다. 벤치마크 결과의 차이에 관계없이 객체 성능이 대부분의 어레이 케이스보다 나쁘지 않다는 것을 일관되게 보여주는 것 같습니다.

나는 또한 토끼 마크를 프로파일링했기 때문에 여기에서 일반적으로 pixi에 대한 성능 결론을 도출하는 것을 피하고 싶습니다. Chrome에서는 프로그램 총 시간의 50% 이상을 Sprite.calculateVertices() (40% ish)로 보내고 TransformStatic.updateTransform() (11% ish) Firefox는 두 배 빠르게 실행되는 것처럼 보이지만 비율은 이 2가지 기능에 소요된 시간은 여전히 ​​일정합니다.

주제에서 너무 벗어나는 것을 피하고 싶지만 이 bunnymark 프로파일링을 수행할 때 es5 getters/setters의 사용이 크롬의 성능 저하와 관련이 있을 수 있다고 생각하기 시작했습니다. https: //jsperf.com/es5-getters-setters-versus-getter-setter-methods/10

여기 슬랙스 하고 계시는 분들 계신가요? 여기에서 메시지를 전달하는 것보다 반 실시간으로 채팅하는 것이 더 쉬울 것이라고 생각합니다.

@mreinstein에 이메일 시겠습니까 ? 슬랙으로 초대합니다👍

@englercj가 말한

작은 업데이트: Float64Array 기반 https://github.com/pixijs/pixi-projection/blob/master/src/Matrix2d.ts 에 3x2 대신 3x3 매트릭스가 있습니다.

이 스레드는 닫힌 후 최근 활동이 없었기 때문에 자동으로 잠겼습니다. 관련 버그에 대한 새 문제를 여십시오.