تستخدم Google تكنولوجيا الذكاء الاصطناعي لترجمة المحتوى إلى لغتك المفضّلة، وقد تتضمّن بعض الأخطاء.

الميزات الجديدة في WebGPU (الإصدار 120 من Chrome)

François Beaufort

إتاحة قيم النقطة العائمة ذات 16 بت في WGSL

في WGSL، يمثّل نوع f16 مجموعة قيم الفاصلة العائمة ذات 16 بت بتنسيق IEEE-754 binary16 (نصف الدقة). وهذا يعني أنّه يستخدم 16 بت لتمثيل رقم الفاصلة العائمة، بدلاً من 32 بت للفاصلة العائمة التقليدية ذات الدقة الفردية (f32). يمكن أن يؤدي هذا الحجم الأصغر إلى تحسينات كبيرة في الأداء، خاصةً عند معالجة كميات كبيرة من البيانات.

للمقارنة، على جهاز Apple M1 Pro، يكون تنفيذ f16نماذج Llama2 7B المستخدَمة في عرض WebLLM التوضيحي للدردشة أسرع بكثير من تنفيذ f32، مع تحسُّن بنسبة% 28 في سرعة التعبئة المسبقة وتحسُّن بنسبة% 41 في سرعة فك الترميز كما هو موضّح في لقطات الشاشة التالية.

لقطة شاشة لعروض WebLLM التوضيحية للمحادثات باستخدام نماذج f32 وf16 Llama2 7B — عروض توضيحية لدردشة WebLLM باستخدام نموذجي Llama2 7B `f32` (على اليمين) و`f16` (على اليسار)

لا تتوافق بعض وحدات معالجة الرسومات مع قيم النقطة العائمة ذات 16 بت. عندما تتوفّر ميزة "shader-f16" في GPUAdapter، يمكنك الآن طلب GPUDevice باستخدام هذه الميزة وإنشاء وحدة تظليل WGSL تستفيد من نوع النقطة العائمة بنصف الدقة f16. لا يمكن استخدام هذا النوع في وحدة تظليل WGSL إلا إذا فعّلت إضافة f16 WGSL باستخدام enable f16;. بخلاف ذلك، ستؤدي الدالة createShaderModule() إلى إنشاء خطأ في التحقّق. اطّلِع على المثال البسيط التالي والمشكلة dawn:1510.

const adapter = await navigator.gpu.requestAdapter();
if (!adapter.features.has("shader-f16")) {
  throw new Error("16-bit floating-point value support is not available");
}
// Explicitly request 16-bit floating-point value support.
const device = await adapter.requestDevice({
  requiredFeatures: ["shader-f16"],
});

const code = `
  enable f16;

  @compute @workgroup_size(1)
  fn main() {
    const c : vec3h = vec3<f16>(1.0h, 2.0h, 3.0h);
  }
`;

const shaderModule = device.createShaderModule({ code });
// Create a compute pipeline with this shader module
// and run the shader on the GPU...

من الممكن توفير كلا النوعين f16 وf32 في رمز وحدة التظليل WGSL باستخدام alias استنادًا إلى توفّر ميزة "shader-f16" كما هو موضّح في المقتطف التالي.

const adapter = await navigator.gpu.requestAdapter();
const hasShaderF16 = adapter.features.has("shader-f16");

const device = await adapter.requestDevice({
  requiredFeatures: hasShaderF16 ? ["shader-f16"] : [],
});

const header = hasShaderF16
  ? `enable f16;
     alias min16float = f16;`
  : `alias min16float = f32;`;

const code = `
  ${header}

  @compute @workgroup_size(1)
  fn main() {
    const c = vec3<min16float>(1.0, 2.0, 3.0);
  }
`;

تجاوز الحدود

الحد الأقصى لعدد البايتات اللازمة لتخزين عيّنة واحدة (بكسل أو بكسل فرعي) من بيانات ناتج مسار العرض، في جميع مرفقات الألوان، هو 32 بايت تلقائيًا. يمكنك الآن طلب ما يصل إلى 64 من خلال استخدام الحدّ الأقصى maxColorAttachmentBytesPerSample. اطّلِع على المثال التالي والمشكلة dawn:2036.

const adapter = await navigator.gpu.requestAdapter();

if (adapter.limits.maxColorAttachmentBytesPerSample < 64) {
  // When the desired limit isn't supported, take action to either fall back to
  // a code path that does not require the higher limit or notify the user that
  // their device does not meet minimum requirements.
}

// Request highest limit of max color attachments bytes per sample.
const device = await adapter.requestDevice({
  requiredLimits: { maxColorAttachmentBytesPerSample: 64 },
});

تمت زيادة حدود maxInterStageShaderVariables وmaxInterStageShaderComponents المستخدَمة للتواصل بين المراحل على جميع المنصات. لمزيد من التفاصيل، يمكنك الاطّلاع على المشكلة dawn:1448.

بالنسبة إلى كل مرحلة من مراحل التظليل، يكون الحدّ الأقصى لعدد إدخالات تصميم مجموعة الربط في تصميم مسار العرض الذي يمثّل مخازن مؤقتة للتخزين هو 8 تلقائيًا. يمكنك الآن طلب ما يصل إلى 10 أذونات باستخدام الحدّ الأقصى maxStorageBuffersPerShaderStage. اطّلِع على المشكلة dawn:2159.

تمّت إضافة حدّ جديد maxBindGroupsPlusVertexBuffers. يتكوّن من الحدّ الأقصى لعدد خانات مجموعة الربط ومخزن مؤقت للرؤوس المستخدَمة في الوقت نفسه، مع احتساب أي خانات فارغة أسفل الفهرس الأعلى. القيمة التلقائية هي 24. يمكنك الاطّلاع على المشكلة dawn:1849.

تغييرات على حالة استنسل العمق

لتحسين تجربة المطوّرين، لم يعُد من الضروري دائمًا استخدام سمات حالة العمق والقطع depthWriteEnabled وdepthCompare: لا تكون depthWriteEnabled مطلوبة إلا للتنسيقات التي تتضمّن عمقًا، ولا تكون depthCompare مطلوبة للتنسيقات التي تتضمّن عمقًا إذا لم يتم استخدامها على الإطلاق. يمكنك الاطّلاع على المشكلة dawn:2132.

تعديلات على معلومات المحوّل

تتوفّر الآن سمات معلومات المحوّل البرمجي غير العادية type وbackend عند طلب requestAdapterInfo() عندما يفعّل المستخدم العلامة "ميزات مطوّري WebGPU" في chrome://flags/#enable-webgpu-developer-features. يمكن أن تكون قيمة type "وحدة معالجة رسومات منفصلة" أو "وحدة معالجة رسومات مدمجة" أو "وحدة معالجة مركزية" أو "غير معروفة". قيمة backend هي إما "WebGPU" أو "D3D11" أو "D3D12" أو "metal" أو "vulkan" أو "openGL" أو "openGLES" أو "null". يمكنك الاطّلاع على المشكلة dawn:2112 والمشكلة dawn:2107.

لقطة شاشة من https://webgpureport.org تعرض معلومات حول الواجهة الخلفية والنوع في معلومات المحوّل — معلومات المحوّل الخلفي ونوعه المعروضَين على https://webgpureport.org.

تمت إزالة مَعلمة القائمة unmaskHints الاختيارية في requestAdapterInfo(). يمكنك الاطّلاع على المشكلة dawn:1427.

تحديد كمية طلبات البحث المستندة إلى الطوابع الزمنية

تتيح طلبات البحث عن الطوابع الزمنية للتطبيقات قياس وقت تنفيذ أوامر وحدة معالجة الرسومات بدقة تصل إلى جزء من مليار من الثانية. ومع ذلك، تجعل مواصفات WebGPU طلبات الطوابع الزمنية اختيارية بسبب المخاوف بشأن هجمات التوقيت. يرى فريق Chrome أنّ تحديد عدد خانات الأرقام العشرية في طلبات البحث عن الطوابع الزمنية يقدّم حلاً وسطًا جيدًا بين الدقة والأمان، وذلك من خلال تقليل الدقة إلى 100 ميكروثانية. يمكنك الاطّلاع على المشكلة dawn:1800.

في Chrome، يمكن للمستخدمين إيقاف تحديد الكمية للوقت من خلال تفعيل العلامة "ميزات مطوّري WebGPU" على chrome://flags/#enable-webgpu-developer-features. يُرجى العِلم أنّ هذا الخيار وحده لا يفعّل ميزة "timestamp-query". لا يزال تنفيذها تجريبيًا، وبالتالي يتطلّب تفعيل العلامة "Unsafe WebGPU Support" في chrome://flags/#enable-unsafe-webgpu.

في Dawn، تمت إضافة زر تبديل الجهاز جديد باسم "timestamp_quantization" وهو مفعَّل تلقائيًا. يوضّح المقتطف التالي كيفية السماح باستخدام ميزة "الاستعلام المستند إلى الطابع الزمني" التجريبية بدون تحديد كمية الطابع الزمني عند طلب جهاز.

wgpu::DawnTogglesDescriptor deviceTogglesDesc = {};

const char* allowUnsafeApisToggle = "allow_unsafe_apis";
deviceTogglesDesc.enabledToggles = &allowUnsafeApisToggle;
deviceTogglesDesc.enabledToggleCount = 1;

const char* timestampQuantizationToggle = "timestamp_quantization";
deviceTogglesDesc.disabledToggles = &timestampQuantizationToggle;
deviceTogglesDesc.disabledToggleCount = 1;

wgpu::DeviceDescriptor desc = {.nextInChain = &deviceTogglesDesc};

// Request a device with no timestamp quantization.
myAdapter.RequestDevice(&desc, myCallback, myUserData);

ميزات التنظيف الشامل

تمت إعادة تسمية الميزة التجريبية "timestamp-query-inside-passes" إلى "chromium-experimental-timestamp-query-inside-passes" لتوضيح أنّ هذه الميزة تجريبية ومتاحة فقط في المتصفّحات المستندة إلى Chromium في الوقت الحالي. يمكنك الاطّلاع على المشكلة dawn:1193.

تمت إزالة ميزة "pipeline-statistics-query" التجريبية التي تم تنفيذها جزئيًا فقط، لأنّه لم يعُد يتم تطويرها. يُرجى الاطّلاع على المشكلة chromium:1177506.

هذا يشمل بعض النقاط الرئيسية فقط. اطّلِع على قائمة عمليات الدمج الشاملة.