تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

الميزات الجديدة في 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". راجِع issue dawn:2112 وissue dawn:2107.

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

تمت إزالة مَعلمة القائمة unmaskHints الاختيارية في requestAdapterInfo(). راجِع الإصدار dawn:1427.

تجميع طلبات البحث عن الطوابع الزمنية

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

في Chrome، يمكن للمستخدمين إيقاف ميزة تجزئة الطوابع الزمنية من خلال تفعيل الميزة التجريبية "WebGPU Developer Features" في الإصدار 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.

تمت إزالة الميزة التجريبية "طلب-إحصاءات-المسار" التي تم تنفيذها جزئيًا فقط لأنّه لم يعُد يتم تطويرها. راجِع المشكلة chromium:1177506.

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