Three.js: هل سيكون هناك عارض قائم على WebGPU؟

تم إنشاؤها على ٩ مارس ٢٠١٩  ·  20تعليقات  ·  مصدر: mrdoob/three.js

أشعر بالفضول لأن موقع Three.js لديه خطة لدعم WebGPU. هل هو ممكن؟

Question

التعليق الأكثر فائدة

يمكنني أن أؤكد لكم أننا لن ننسى ذلك ... 😁

ال 20 كومينتر

من الناحية النظرية في المستقبل البعيد ، ولكن كما تعلم ، لا تزال مجموعة WebGPU تتحدث بنشاط / تتماشى مع تشكيل المقترحات / المواصفات / المسودات الأولى. سوف تمر سنوات قبل أن يكون لدينا مواصفات كاملة وتنفيذ معياري يعمل.

ومع ذلك ، أوصي بالمشاركة / المتابعة في تطوير WebGPU هنا: https://github.com/gpuweb/gpuweb/wiki و https://www.w3.org/community/gpu/

إذا تبين أن WebGPU قوي كما نأمل جميعًا في أن تكون مكتبات مثل Three.js ، فمن المحتمل أن تتم إعادة كتابتها من البداية من أجل الاستفادة الكاملة منها.

تضمين التغريدة
نعم اوافق. سأكون المستقبل البعيد.
هل من المستحيل إضافة عارض WebGPU في three.js دون إعادة كتابة النواة من البداية؟ هل يجب علينا إعادة كتابة المحرك بالكامل (API) في threejs من البداية؟ أعتقد أنه حتى إذا ظهر WebGPU ، فمن المحتمل جدًا أن يتعايشوا معًا (WebGL / WebGPU) لفترة من الوقت. لا أعتقد أن WebGPU سيقتل كل نظام WebGL البيئي.
ومع ذلك ، أفترض أن WebGPU سيكون قويًا جدًا إذا كان يدعم أصلاً وبشكل مباشر بخلاف أن WebGL هو واجهة برمجة تطبيقات غير مباشرة لبرنامج تشغيل الرسومات ؛ويريد Google وغيره من اللاعبين الكبار ذلك من أجل أداء DeepLearning أفضل وتجربة رسومية عالية الأداء في المتصفح

لدى ThreeJS العديد من العارضين المختلفين بالفعل - WebGLRenderer و WebGL2Renderer و CSS3DRenderer و SVGRenderer ... يمكن التعامل مع WebGPU بشكل مشابه عندما تكون واجهة برمجة التطبيقات جاهزة. من الممكن إجراء تغييرات أعمق في المكتبة بمرور الوقت أيضًا.

إغلاق هذه المشكلة في الوقت الحالي ، على الرغم من أنني متحمس لإتاحة واجهات برمجة التطبيقات من الجيل التالي أيضًا. :)

تضمين التغريدة
في الواقع .. تتميز Three.js بالمرونة بحيث يمكنها تنفيذ WebGPU في المستقبل ، أليس كذلك؟

وفقًا لاقتراح WebGPU ، ذكروا عن Three.js deverlopers كواحد من الجماهير المستهدفة الرئيسية.

https://gpuweb.github.io/admin/cg-charter.html

مطورو إطار عمل JavaScript الذين يقومون ببناء مكتبات GPU ، بهدف استخدامها في محتوى الويب ، ولكنهم يوفرون واجهة برمجة تطبيقات ذات مستوى أعلى ويخفون الكثير من الرسومات منخفضة المستوى وتفاصيل الحساب عن مستخدميهم. على سبيل المثال ، three.js.

سؤالي هو أنهم يستخدمون لغة تظليل أخرى تسمى WHLSL.
https://github.com/gpuweb/WHLSL

سؤالي هو أنهم يستخدمون لغة تظليل أخرى تسمى WHLSL.

"سنعبر ذلك الجسر عندما نصل إليه".

تم الإعلان عن @ Google I / O مع دعم تجريبي في Chrome Canary لـ OSX متاح الآن:
https://www.youtube.com/watch؟v=K2JzIUIHIhc

أعلن Babylon.js الدعم الكامل له عندما يخرج. تحقق من ذلك هنا:
https://forum.babylonjs.com/t/webgpu-is-coming-to-babylon-js/3122

آمل أن يتبع فريق ThreeJS زمام المبادرة.

لست متأكدا لماذا أغلق هذا كما ذكر الدعم المحتمل. من الناحية المنطقية ، تركنا القضايا مفتوحة "لتتبعها". إذا قمت بإغلاقه ، فإنك تنسى فقط ... ما لم تكن هناك مشكلة أخرى لتتبعها.

يمكنني أن أؤكد لكم أننا لن ننسى ذلك ... 😁

لكنني لست مشرفًا. أنا شخصياً سأتبع إطار العمل الأول الذي يتبنى webgpu. وهذه النقطة ليست أنا. هي الرسالة التي تعطيها يا رفاق في ختام هذا. إنه مثل "شيء رائع ، شيء مؤكد ، لكنني لا أهتم. يمكن أن يظل هناك في طي النسيان".

ملاحظة. قرأتها خاطئة ، واعتقدت أنها كانت "يمكنني أن أؤكد أنك لن تنساها"

MichelDiz تم فتح هذه المشكلة للسؤال عما إذا كنا نخطط لدعم WebGPU. تمت الإجابة على السؤال: نحن بالتأكيد نخطط لدعم WebGPU. ربما يكون من السابق لأوانه العمل على ذلك ، ولكن سيتم فتح قضايا جديدة عندما نكون مستعدين لمناقشة هذا الأمر.

TimvanScherpenzeel يجب إعادة كتابة بعض الأجزاء التي تم تجريدها بعيدًا عن المستخدمين ، لكن اقتراح الأمر برمته يجب "إعادة كتابته من الصفر" هو مبالغة كبيرة. سيكون للهندسات العازلة نفس التنسيق. تمامًا مثل WebGL ، يعتمد WebGPU أيضًا على تظليل GLSL -> WHLSL. يبدو أن تنسيق glTF الذي أصبح معيار WebGL سيكون أيضًا معيار WebGPU. ستبقى جميع واجهات برمجة تطبيقات Three.js الأكثر استخدامًا بنسبة 99٪ دون تغيير بينما سيكون عارض WebGPU الجديد تحت الغطاء ، ونأمل أن يجلب تعزيزًا كبيرًا للأداء ويفتح إمكانية عرض مشاهد كبيرة بمعدل إطارات في الثانية عالية.

تحية للجميع،
شكرا جزيلا للتحديثات على هذا واحد!
أردت فقط مشاركة وجهة نظري حول ميزات مثل هذه. في حالتنا ، لا نستخدم دائمًا WebGL لتطبيقات المستهلك. لدينا تجارب WebGL التي تصور مجموعات بيانات كبيرة جدًا حيث تبلغ الأصول حوالي 1 جيجابايت ويتم تقديمها محليًا على أجهزة ثابتة حيث يمكننا التحكم في المتصفحات وأعلامها لتمكين WebGPU. لذلك حتى لو كنا في الوضع التجريبي ، يمكننا بالتأكيد أن نحصل على دعم لذلك. أفهم أننا أقلية ، لكنني أردت فقط إضافة وجهة النظر هذه في المحادثة.

sinokgr كيف يساعد WebGPU في عرض أصول 1 جيجابايت؟ بقدر ما أفهم أن هياكل البيانات لبيانات الهندسة هي نفسها WebGL.

شكرا على الرد mrdoob . لكي أكون صادقًا بنسبة 100 ٪ ، لن أدعي أنني أفهم الاختلافات الكافية وأن المعلومات التي أجدها عبر الإنترنت غامضة للغاية (وفقًا لبحثي على أي حال). الشعور الأساسي الذي أحصل عليه هو من الأشياء التي قرأتها مثل الرسالة الأخيرة من DVLP التي

سيعزز الأداء بشكل كبير ويفتح إمكانية عرض المشاهد الكبيرة بمعدل إطارات عالية في الثانية.

تجعلني أعتقد أننا سنشهد على الأقل بعض التحسينات. قد يكون هذا ، ما مدى سرعة تحميل هذه الأصول على سبيل المثال ، ربما أفضل إطارات في الثانية؟ لست متأكدا.

سيبقى التحميل الأولي على الذاكرة العادية كما هو ولكن واجهة GPU API بأكملها ستكون أسرع ، لذا من اللحظة التي يتم فيها تضمين GPU يجب أن تكون أسرع. إليك كيف أرى من أين سيأتي تعزيز الأداء:

  1. تحميل ملف النموذج إلى المتصفح - بنفس السرعة
  2. تحليل النموذج وتحميل الهندسة إلى مخزن مؤقت للصفيف - نفس السرعة
  3. تحميل برامج GPU - بشكل أسرع
  4. تحميل القوام - في البداية بنفس السرعة ولكن بشكل أسرع عند التسليم إلى وحدة معالجة الرسومات
  5. نقل الهندسة إلى GPU - بشكل أسرع
  6. قم بإجراء سلسلة من مكالمات السحب لعرض إطار - بشكل أسرع

شكرا جزيلا على الشرح DVLP . تبدو النقطتان 5 و 6 شيقتين للغاية بالنسبة لي لأن لدينا آلاف الأشياء التي تحتوي على الكثير من المواد.

قد يستغرق الأمر وقتًا طويلاً حتى يتم اعتماد WebGPU على نطاق واسع. حتى ذلك الحين يمكنك تسريع كل شيء باستخدام تثبيت الشبكة
https://threejs.org/docs/#api/en/objects/InstancedMesh

أخشى أنه لا يمكننا استخدام التثبيت ، فجميع الكائنات فريدة من نوعها DVLP

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات