Lời kêu gọi kỹ thuật của nhà phát triển Anukari gửi tới Apple

 (anukari.com)
1 điểm bởi GN⁺ 2025-05-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • Anukari là bộ tổng hợp âm thanh vật lý 3D thời gian thực, nên phải tính toán mô hình spring-mass quy mô lớn trên GPU; nhưng trên macOS chạy Apple silicon, nếu xung nhịp GPU không tăng đủ cao thì khó đáp ứng yêu cầu độ trễ âm thanh
  • Cấu trúc DAW gọi plugin theo từng khối bộ đệm âm thanh kết hợp với heuristic quản lý năng lượng của macOS khiến GPU có vẻ như nghỉ giữa các khối, nên có thể bị giữ ở trạng thái hiệu năng thấp
  • Trong Metal profiler của Xcode Instruments, khi đặt Performance State ở Maximum thì hoạt động bình thường, còn ở Minimum thì kém đi rõ rệt, xác nhận nút thắt cốt lõi là tốc độ xung nhịp GPU
  • Hiện tại, Anukari dùng một biện pháp vòng tránh “waste makes haste” bằng spin kernel nhỏ để tăng tải GPU một cách nhân tạo, nhưng trên một số phần cứng Apple Pro/Max vấn đề vẫn còn
  • Nhà phát triển đề nghị đội ngũ Apple Metal hỗ trợ mở rộng Audio Workgroup sang GPU, thêm tùy chọn độ nhạy thời gian thực cho MTLCommandQueue, hoặc hướng dẫn giải pháp hiện có; họ cho rằng trên Windows không cần spin loop tương tự

Vấn đề hiệu năng GPU trên macOS mà Anukari gặp phải

  • Anukari 3D Physics Synthesizer mô phỏng theo thời gian thực một mô hình vật lý spring-mass quy mô lớn để tạo âm thanh
  • Để hỗ trợ số lượng đáng kể đối tượng vật lý, cần có GPU; mã vật lý gần với nút thắt ALU hơn là nút thắt bộ nhớ
  • Trạng thái có thể thay đổi của mô phỏng được lưu trong threadgroup memory của GPU
    • Đây là cấu trúc gần giống bộ đệm L1 cấp phát thủ công, nên rất nhanh
  • Cách sử dụng thông thường là chạy dưới dạng plugin AU hoặc VST3 bên trong DAW như Pro Tools, Ableton
    • DAW gọi Anukari theo từng khối bộ đệm âm thanh
    • Với mỗi khối, Anukari chạy kernel mô phỏng vật lý trên GPU, chờ kết quả rồi trả về
  • Khối bộ đệm âm thanh có thể hấp thụ độ trễ lập lịch kernel GPU bằng cách dàn trải nó trên nhiều sample, nhưng thời gian chạy của chính kernel vẫn mang tính quyết định

Xung đột giữa quản lý năng lượng macOS và âm thanh thời gian thực

  • Apple silicon có thể hạ tốc độ xung nhịp của chip để tiết kiệm điện, và macOS duy trì xung nhịp thấp nếu đánh giá nhu cầu xử lý là thấp
  • Cách Anukari chạy trong DAW không khớp tốt với cách macOS đánh giá nhu cầu GPU
  • GPU trở nên nhàn rỗi giữa các khối bộ đệm âm thanh, nên tải trung bình có thể chỉ hiện khoảng 60% chẳng hạn
    • Không thể biết heuristic thực tế của macOS, nhưng tác giả suy đoán có thể là một kiểu tương tự load average
    • Mức tải này có thể không vượt ngưỡng để tăng xung nhịp GPU
  • Anukari cần độ trễ thấp để đáp ứng ràng buộc thời gian thực, và vì thế cần xung nhịp GPU cao
  • Không rõ xung nhịp GPU Apple có thể hạ thấp đến mức nào, nhưng có thể thấp đến mức khiến Anukari không sử dụng được

Xác nhận vấn đề xung nhịp bằng Metal profiler

  • Bằng Metal profiler của Apple Instruments đi kèm Xcode, tác giả xác nhận Anukari bị ALU-bound
  • Metal profiler cho phép chọn “Performance State” của Metal trong khi profiling
    • Thiết lập này không thể cấu hình bên ngoài profiler
  • Ở Maximum performance state, Anukari hoạt động hoàn hảo
  • Ở Minimum performance state, hoạt động kém đi rõ rệt
  • Sự khác biệt giữa hai trạng thái cho thấy tốc độ xung nhịp GPU là cốt lõi của vấn đề hiệu năng Anukari

Biện pháp vòng tránh “waste makes haste” và giới hạn

  • Vì macOS không tăng xung nhịp GPU vào thời điểm cần thiết, Anukari dùng một biện pháp vòng tránh riêng
  • Chạy một tác vụ GPU thứ hai song song với tác vụ GPU tính toán âm thanh để tạo tải trung bình cao, khiến macOS tăng xung nhịp
    • Tác vụ này được tinh chỉnh để dùng ít tài nguyên GPU nhất có thể nhưng vẫn kích thích heuristic xung nhịp
    • Về thực chất, đây là một spin loop làm nóng GPU
  • Chiến lược này được gọi là “waste makes haste”, và đã được ghi chép chi tiết trong devlog liên quan
  • Trên MacBook M1 của nhà phát triển, cách này đã giải quyết hoàn toàn vấn đề và Anukari chạy ổn định
  • Tuy nhiên, sau khi phát hành Anukari Beta, một số người dùng macOS gặp vấn đề
    • Đặc biệt, người dùng phần cứng Apple Pro hoặc Max có vẻ gặp nhiều vấn đề hiệu năng
    • Bài viết nêu giả thuyết về khả năng xung nhịp độc lập theo từng GPU chiplet, hoặc spin workload có thể quá thận trọng đối với GPU mạnh hơn

Hướng giải quyết đề nghị Apple

  • Với tiền đề rằng kỹ sư Apple sẽ hiểu rõ hơn, tác giả đề xuất một số giải pháp khả dĩ
  • Giải pháp 1: Mở rộng khái niệm Audio Workgroup sang cả xử lý GPU
    • Xử lý âm thanh của macOS được thực hiện trong một thread hoặc nhóm thread gọi là Audio Workgroup
    • Hệ điều hành hiểu rằng các thread này có ràng buộc thời gian thực và cấp ưu tiên cho chúng
    • Có thể coi MTLCommandQueue do thread Audio Workgroup quản lý là xử lý thời gian thực và điều chỉnh xung nhịp GPU theo đó
  • Giải pháp 2: Cung cấp tùy chọn trong Metal API để đánh dấu độ nhạy thời gian thực cho MTLCommandQueue
    • Xung nhịp của GPU chiplet xử lý queue đó có thể được điều chỉnh tương ứng
  • Giải pháp 3: Nếu đã có cách đạt được chức năng mong muốn, chỉ cần Apple cho biết là đủ
  • Ở đầu bài viết có bổ sung rằng Apple đã liên hệ và nội dung liên quan nằm trong bài viết riêng

So sánh với Game Mode và Windows

  • Game Mode của Apple trông có vẻ giống thứ Anukari cần, nhưng khó áp dụng
    • Game Mode hoạt động theo từng tiến trình
    • Anukari chủ yếu được dùng như plugin bên trong tiến trình khác, và tiến trình đó không hỗ trợ Game Mode
    • Anukari không thể trực tiếp điều khiển việc này
    • Game Mode cũng yêu cầu fullscreen, trong khi Anukari thường không chạy fullscreen
  • Trên Windows, vấn đề này không xảy ra
    • Không rõ là do Windows trao cho người dùng nhiều quyền điều khiển trạng thái hiệu năng hơn, hay do driver NVIDIA ít thận trọng hơn về tiêu thụ điện
    • Trên Windows không cần spin loop
  • Bài viết so sánh rằng PC Windows có GPU yếu vẫn chạy Anukari tốt, trong khi Mac M4 Max đắt tiền có thể bị stutter

Vì sao pipelining không phù hợp

  • Cách pipeline hóa mã GPU để làm GPU bão hòa phù hợp với tác vụ thiên về throughput, nhưng Anukari là tác vụ nhạy với độ trễ
  • Nếu lập lịch trước nhiều kernel mô phỏng vật lý, CPU có thể chuẩn bị khối kế tiếp trong khi GPU xử lý khối âm thanh hiện tại
  • Nhưng pipelining tăng throughput đổi lại bằng việc tăng độ trễ
  • Mỗi lần chạy kernel của Anukari cần truy cập dữ liệu đầu vào âm thanh thời gian thực như đầu vào micro
  • Không thể dùng speculative execution để xử lý trước khối âm thanh tiếp theo vì chưa có dữ liệu đầu vào cần thiết

Vấn đề khi đưa spin kernel vào cùng MTLCommandQueue

  • Nếu nguyên nhân thực sự là spin kernel và physics kernel chạy trên các GPU chiplet khác nhau, đưa chúng vào cùng MTLCommandQueue có thể trông như một giải pháp
  • Thực tế, tác giả đã thử cách này nhưng không hoạt động
  • Lý do là Anukari là tác vụ nhạy với độ trễ
    • Spin kernel đôi khi chạy hơi lâu
    • Khoảng thời gian đó lấn vào thời gian chạy của physics kernel
  • Tác giả cũng thử dùng spin kernel nhỏ và volatile unified memory để CPU ghi cờ “exit kernel early”
  • Dù có các cơ chế này, vẫn có trường hợp spin kernel lấn vào thời gian của physics kernel

Vì sao GPU kernel hedging khó thực hiện

  • Tác giả cũng xem xét cách chạy nhiều bản sao physics kernel rồi dùng kết quả hoàn tất đầu tiên, giống request hedging trong hệ thống phân tán
  • Cách này có thể giảm độ trễ đuôi và độ phân tán độ trễ, đồng thời tạo tải GPU để khiến hệ điều hành nâng trạng thái hiệu năng
  • Nhưng với Anukari, có nhiều vấn đề
    • Nếu một physics kernel chạy lâu hơn một chu kỳ khối âm thanh, stream kernel đó sẽ bị tụt lại
    • Stream kernel bị tụt lại phải bắt kịp ở các khối tương lai, và cần fast-forward bằng cách sao chép trạng thái nội bộ của stream khác
  • Việc sao chép trạng thái nội bộ rất tốn kém
    • Trạng thái nội bộ lớn nhất là bộ đệm âm thanh cho delay line
    • Mỗi micro lưu 1 giây âm thanh quá khứ
    • Kích thước là 48,000 samples * 50 mics * 2 channels * 16 voices * 4 bytes, tức 307MB
    • Ở sample rate cao hơn, kích thước còn lớn hơn
  • Để xử lý hiệu quả, cần theo dõi chính xác vùng dirty của từng hedged kernel stream và chỉ sao chép phần đó
    • Nhưng bố cục bộ nhớ của buffer được tối ưu cho workload đọc của physics kernel
    • Ngay cả khi chỉ sao chép tối thiểu, vẫn phải sao chép các vùng rải rác trên toàn buffer nên chậm
  • Thay đổi mô hình của người dùng cũng phải được truyền tới mọi hedged kernel
  • Physics kernel có GPU footprint lớn hơn nhiều so với spin kernel “waste makes haste”
    • Hedging tạo thêm nhiều tải GPU vô ích hơn, và có thể làm giảm số lượng instance Anukari có thể chạy song song
    • Các hedge kernel cũng có thể cạnh tranh với nhau và khiến tất cả đều chậm lại

Các tối ưu hóa đã thực hiện và lý do cần GPU

  • Mô phỏng Anukari bị ALU-bound, nên không còn nhiều chỗ cho các tối ưu hóa thông thường như cải thiện mẫu truy cập bộ nhớ
  • Để tăng hiệu năng, cần tối ưu throughput số học
    • Dùng phép toán FP16 ở những nơi có thể để bão hòa ALU Apple tốt hơn
    • Dùng micro-benchmark để điều chỉnh thứ tự lệnh
    • Đưa toàn bộ trạng thái vật lý vào L1 memory
    • Sắp xếp lại thứ tự load để vectorization
  • Tác giả cũng tận dụng việc các thread trong SIMD-group của Apple nhìn chung chia sẻ instruction pointer
    • Các đối tượng vật lý khác nhau có branch path phân kỳ mạnh
    • Nếu mô phỏng hai loại đối tượng trong cùng một SIMD-group, instruction masking sẽ làm chậm
    • Để tránh điều này, tác giả tối ưu động bố cục bộ nhớ của đối tượng vật lý nhằm giảm số loại đối tượng chạy trong cùng một SIMD-group
    • Tối ưu này được trình bày chi tiết trong the new warp alignment optimizer
  • Vẫn còn dư địa tối ưu số học, nhưng tác giả cho rằng chỉ cải thiện ở mức vài điểm phần trăm một chữ số
  • Trên máy mạnh, Anukari có thể mô phỏng 768–1024 đối tượng vật lý
    • Mỗi đối tượng có thể kết nối tùy ý với đối tượng khác
    • Các đối tượng thường thực hiện implicit Euler integration ở sample rate âm thanh 48.000 sample mỗi giây
    • Mỗi đối tượng có 3–10 tham số hoạt động
    • Một số hành vi bao gồm các phép toán đắt như vector rotation, exp(), log()
    • Để hỗ trợ polyphony, toàn bộ mô phỏng vật lý được chạy thành tối đa 16 bản sao song song
  • CPU không thể thực hiện cách này; cần rất nhiều ALU của GPU, khả năng kiểm soát bố cục L1 cache, và các cấu trúc đồng thời như threadgroup_barrier
  • Anukari không thể tồn tại nếu thiếu xử lý GPU

Vì sao GPU Audio API không phải giải pháp

  • CEO của GPU Audio, Alexander Talashov, từng nói rằng vấn đề có thể được giải quyết nếu Anukari dùng GPU Audio API
  • Nhà phát triển đánh giá GPU Audio là một sản phẩm tốt, và giới thiệu đây là sản phẩm giúp DSP tiếp cận được GPU
  • Nhưng tác giả cho rằng GPU Audio không hữu ích với Anukari
  • Khác với ứng dụng DSP truyền thống, Anukari gần với bộ tích phân phương trình vi phân số hơn
    • Dù có một số phần DSP, phần lớn tính toán là Eulerian integration
    • DSP như nén tín hiệu micro trong thế giới vật lý được xử lý inline bên trong tính toán vật lý trên GPU
  • Anukari đang lập trình trực tiếp GPU ở tầng thấp của Metal
  • Điều cần thiết là Apple giúp tăng tốc độ xung nhịp GPU một cách ổn định

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-05-07
Ý kiến trên Hacker News

  • Có lẽ có người đã thấy Anukari trong bài Show HN của tôi: https://news.ycombinator.com/item?id=43873074

    Trong thread đó có nhắc đến hiệu năng macOS. Anukari chạy tốt trên hầu hết Apple silicon, bao gồm cả M1 bản cơ bản, và toàn bộ thử nghiệm của tôi cũng thực hiện trên M1 cơ bản, kết quả rất tuyệt. Phần cứng thật sự đáng kinh ngạc

    Tuy nhiên để nó hoạt động, tôi phải triển khai một cách workaround kỳ quặc nhằm khiến macOS tăng tốc độ xung nhịp GPU để xử lý âm thanh đủ nhanh. Heuristic thông thường mà macOS dùng để quyết định trạng thái hiệu năng GPU không hiểu được workload đặc thù của Anukari

    Vì vậy cuối cùng tôi đã viết lại toàn bộ tình huống với mức chi tiết hơi quá, và muốn nhờ mọi người giúp kết nối với đúng người ở Apple, có lẽ là người phụ trách Metal API. Xin hãy giúp :)

    • Bạn nói đó là “một bài rất dài và rất kỹ thuật”, nhưng khi đọc hết thì tôi thấy nó không quá dài, lại rất rõ ràng, được viết tốt và hữu ích. Bài viết hay lắm

      Tôi chưa từng sở hữu Mac, PC của tôi cũng đã cũ và không có GPU đúng nghĩa, nên khả năng tôi dùng thử Anukari ngay là thấp, nhưng nó trông thật sự rất hay nên hơi tiếc. Mong vấn đề sớm được giải quyết

    • Không biết bạn đã thử entitlement này chưa: https://developer.apple.com/documentation/bundleresources/en...

      Tôi tò mò liệu com.apple.developer.sustained-execution có hoạt động theo chiều ngược lại không

    • Bài viết thú vị và vấn đề cũng thú vị. Tôi nghĩ lý do ý tưởng chạy tác vụ trên cùng một queue thất bại rốt cuộc cũng là cùng lý do với vấn đề ban đầu. Vì tốc độ xung nhịp biến thiên, việc lập lịch chính xác trở nên bất khả thi; tùy hệ điều hành đặt xung GPU thế nào mà thời điểm dừng spin lệch khỏi thời điểm lý tưởng, tạo ra kiểu aliasing

      Nếu vậy thì có thể tác vụ spin chưa đủ phức tạp để đẩy GPU lên xung tối đa. Nếu thật sự đang chạy ở hiệu năng cao nhất, bạn lẽ ra phải có thể căn ổn định thời điểm kết thúc spin mà không cần thêm PLL phần mềm. Tôi chưa thấy mô tả chi tiết spin được triển khai thế nào, nhưng một vòng lặp spin “đầy đủ” hơn, liên tục ép nhiều phần hơn của GPU làm việc, có lẽ sẽ hiệu quả hơn trong việc giữ xung ở mức hiệu năng tối đa

    • Tôi đã bỏ lỡ Show HN, nhưng vừa thấy là nghĩ ngay nó sẽ rất hợp với soundscape ASMR sáng tạo và âm thanh đa chiều nhập vai. Hy vọng bạn hoặc người dùng nào đó sẽ làm demo. Chúc mừng dự án và mong bạn nhận được trợ giúp về vấn đề với Apple

    • Bài viết hay, giải thích rõ ràng nên dễ hiểu. Tôi chắc chắn từng gặp vấn đề giống như bạn mô tả trong những bối cảnh khác

  • Mọi người ơi, đã có hiệu quả. Tôi đã có một cuộc trao đổi rất hiệu quả với đúng người trong đội Metal! Cảm ơn đã giúp thu hút sự chú ý của Apple. Tôi hoàn toàn không ngờ nhận được nhiều sự ủng hộ đến vậy

    https://anukari.com/blog/devlog/productive-conversation-appl...

    • Thật tốt là giờ đã có workaround, nhưng việc thậm chí không thể chia sẻ workaround đó là gì lại trớ trêu thay minh họa đúng câu cuối trong https://news.ycombinator.com/item?id=43904921 về cách Apple giao tiếp

      Kiểu như “đặt giá trị này như thế này rồi đổi thành thế kia thì sẽ chạy. Không có tài liệu, nhưng giờ bạn biết rồi đấy”

      Khi triển khai workaround, hy vọng bạn có thể đặt nó trong một hàm có tên thật lộ liễu, để những người khác gặp các ràng buộc GPU nhạy cảm với độ trễ tương tự ít nhất còn có thể lần ra câu thần chú bằng disassembly

    • HN một lần nữa đã hoàn thành mục đích ban đầu của mình: xuyên thủng rào cản quan liêu trước bộ phận hỗ trợ khách hàng của các tập đoàn lớn

      Chúc mừng dự án và chúc may mắn

  • Tôi từng làm ở hai công ty nổi tiếng có ứng dụng rất nổi tiếng trên Apple App Store

    Nhóm Apple mà chúng tôi trao đổi hoàn toàn không quan tâm đến vấn đề của chúng tôi; thay vào đó, họ thường mời chúng tôi đến văn phòng để bàn về các tính năng mới nhất sẽ công bố tại WWDC, về cơ bản là ép chúng tôi hỗ trợ các tính năng đó. Đó là khởi đầu và cũng là kết thúc của mối quan hệ với họ. Muốn tìm hiểu vì sao phần mềm Apple đầy lỗi không hoạt động, chúng tôi chỉ còn cách mở ticket hỗ trợ kỹ thuật

    Những người phụ trách quan hệ developer của Apple không phải là những người nghiêm túc

    • Như bài gốc phía trên cho thấy, may là trải nghiệm của tôi không phải quy luật chung. Nhưng khoảng 10 năm trước, khi tôi làm ở một công ty có ứng dụng khá nổi tiếng, một bản cập nhật đã phá hỏng hoàn toàn hiệu năng của ứng dụng

      Đúng cùng thời điểm đó, một đối thủ ra mắt ứng dụng không gặp vấn đề hiệu năng. Hóa ra developer của ứng dụng đối thủ đó là người vừa rời Apple không lâu, và đã để lại một cái bẫy không được ghi trong tài liệu trong driver video của Apple khiến ứng dụng của chúng tôi bị hỏng. Chúng tôi phải disassemble binary của đối thủ mới tìm ra thay đổi không được tài liệu hóa và sửa được ứng dụng. Developer đó còn gửi email chế giễu CEO của chúng tôi. Thế giới thật tuyệt vời

  • Metal profiler có một tính năng rất hữu ích cho phép chọn trạng thái hiệu năng của Metal trong khi profiling ứng dụng. Ngoài profiler thì không thể đặt được

    Nhìn vào đó thì có vẻ tồn tại API riêng tư. Có khi đi theo hướng reverse engineering còn dễ hơn chăng? Tất nhiên là trừ trường hợp cần quyền đặc biệt không thể vượt qua nếu không tắt SIP

    • Chắc chắn phải có API riêng tư cho việc này. Trong bài cũng có đoạn như sau

      “Metal profiler có một tính năng rất hữu ích cho phép chọn ‘Performance State’ của Metal trong khi profiling ứng dụng. Ngoài profiler thì không thể đặt được”

      Nếu không phải API riêng tư thì Metal profiler làm sao làm được việc đó? Có thể dùng công cụ debugging nào đó để quan sát profiler và xem bên trong đang xảy ra chuyện gì không?

  • Vấn đề khi công khai API này là quá nhiều nhà phát triển sẽ luôn cưỡng ép bật trạng thái hiệu năng tối đa. Tôi không biết liệu có cách nào thật sự tốt để cung cấp API mà vẫn ngăn được việc đó hay không

    • Trên các thiết bị chạy bằng pin, một ứng dụng đã có vô số cách để lãng phí điện năng. Rốt cuộc, cấu trúc hiện tại vốn đã dựa trên niềm tin rằng các nhà phát triển, dù cố ý hay vô tình, sẽ không chạy những tác vụ tiêu tốn năng lượng một cách không cần thiết. Việc có thêm một API nữa có thể lãng phí điện năng nếu dùng không đúng cách cũng không làm thay đổi quá nhiều

    • Bài viết cũng đề cập đến Game Mode, một tính năng được tối ưu cho những trường hợp như vậy trên các hệ điều hành Apple mới nhất. Khi Game Mode được bật sẽ có thông báo hiện lên, và hầu hết ứng dụng sẽ không muốn điều đó. Cho đến nay tôi chưa thấy trường hợp nào lạm dụng nó

    • Các nhà phát triển hiện vẫn chưa lạm dụng audio workgroup cho mọi thread pool để có được lập lịch P-core và mức ưu tiên cao. Nếu vậy, điều đó gợi ý rằng khi audio workgroup phát lệnh cho GPU, có thể đặt một dạng timeout cho việc GPU hạ xung, dựa trên thời điểm gần nhất workgroup gửi dữ liệu

      Audio trên GPU hiện nay là lĩnh vực rất ngách, nhưng công ty được nhắc trong bài gần đây đã công bố SDK nên nó có thể trở nên phổ biến hơn. Dù vậy tôi vẫn thấy khó thuyết phục. Việc xử lý trên GPU gần như đồng nghĩa với việc không quá quan tâm đến độ trễ, nên tôi nghĩ chỉ cần tăng kích thước buffer vào/ra là được

    • Ngay cả khi API bị lạm dụng, nó vẫn sẽ hiệu quả hơn so với việc chạy tác vụ bận giả để làm cùng một việc. Các ứng dụng vốn đã có thể làm như vậy mà không cần API, hoặc không cần các quyền mà API có thể yêu cầu

    • Cấp quyền thủ công thì sao? Dù có giấu ở đâu đó, khả năng cao các ứng dụng rất ngách vẫn sẽ cần đến nó

      Và ở cấp hệ điều hành thì cứ mặc định từ chối Zoom, Teams, trình duyệt web là được :)

  • Cách tốt nhất để làm việc này:

    1. Lướt qua các video WWDC và tìm kỹ sư trông có vẻ hiểu rõ nhất vấn đề bạn đang gặp

    2. Nếu là Michael Thomson thì gửi email trực tiếp theo dạng mthomson@apple.com

    • Hoặc gửi cho người anh em Pichael của anh ấy theo địa chỉ pthomson

  • Nhân tiện, Anukari nên ra gói âm thanh Mick Gordon và chia doanh thu với ông ấy. Ông ấy đang tạo ra những thứ thật sự điên rồ, và bản demo cũng cực kỳ ấn tượng. Khi đã có một công cụ mạnh như thế này, hợp tác với nghệ sĩ là một hướng kinh doanh tốt và cũng tốt cho thế giới. Nếu bạn thích Mick Gordon, mà tôi thì thích

  • Tôi hoàn toàn không cần ứng dụng này, nhưng nó thật sự rất ngầu. Những ứng dụng như thế này mang niềm vui trở lại với điện toán. Không phải là hiện giờ chẳng còn gì vui, nhưng nó gợi nhớ thời xưa khi có nhiều chương trình giàu tính đồ họa và thử nghiệm hơn lang thang khắp nơi, thậm chí cả demoscene nữa

  • Đừng bỏ lỡ liên kết https://x.com/Mick_Gordon/status/1918146487948919222 ở đoạn áp chót. Đây là demo do Mick Gordon tạo, và @anukarimusic đã trả lời như sau

    “Haha mới là ngày thứ hai sau khi ra mắt mà anh đã hoàn toàn phá nát mọi bản demo tôi làm trong suốt 2 năm dùng nó hằng ngày rồi”

  • Việc cập nhật 1024 đối tượng ở 48kHz có vẻ cũng khả thi trên CPU, tùy cách viết code. Chẳng phải là 48 triệu lần cập nhật mỗi giây sao? Có vẻ phù hợp để dùng OpenMP chạy song song vài vòng lặp trên các core

      1. Để hỗ trợ đa âm (polyphony), Anukari chạy toàn bộ mô hình vật lý với tối đa 16 bản sao. Tức là 16 * 1024 * 48K. Chắc tôi phải cập nhật bài blog

      2. Người dùng có thể kết nối các đối tượng với nhau tùy ý, nên mỗi đối tượng phải đọc và xử lý các kết nối tới N thực thể khác

      3. Để dùng toàn bộ CPU, mỗi bước vật lý đều cần đồng bộ giữa các core, và việc này chậm

      4. Khối lượng xử lý trên mỗi đối tượng khá lớn. Có nhiều hàm siêu việt, dù có thể xấp xỉ, nhưng bản thân tính năng cũng nhiều. Mọi tham số đều có thể được điều chế, phải an toàn với NaN, v.v.

      5. Người dùng muốn chạy nhiều phiên bản Anukari song song cho nhiều track, hiệu ứng, v.v.

      Nhìn theo cách khác thì là 4 GHz / (16 voice * 1024 obj * 4 connections * 48,000 sample) = 1.3 cycles per thing

      GPU xử lý workload này trong nháy mắt. Kiến trúc của nó hoàn toàn phù hợp. Có thể xử lý hoàn toàn song song toàn bộ 16 voice * 1024 obj, đồng bộ ở từng bước cũng đơn giản, và người dùng có thể quản lý cache L1

    • Nếu phép tính đúng thì để tính một sample cần 83 chu kỳ xung nhịp. Với 16 core thì về lý thuyết là 1333 chu kỳ, cũng không nhiều lắm. Càng đúng hơn nếu xét rằng không thể lúc nào cũng dùng CPU gần 100%