Triton compiler'ının temelini oluşturan genel katmanı anlamak için lineer düzenler önemli bir zemin hazırlamıştı. Şimdi ise compiler'ın iç işleyişinde sürekli etkileşimde bulunduğumuz "özel düzenlere" (bespoke layouts) odaklanalım. Geliştiriciler artık Gluon ile doğrudan düzenleri programlayabiliyor ve bu özel düzenleri yazmak daha sezgisel. Özel düzenler derken, bloklu, paylaşımlı ve MMA gibi geleneksel düzenleri kastediyorum. Bunlar, her birinin belirli bir ihtiyaca göre tasarlandığını vurgulamak adına "özel" olarak adlandırılır.
Başlangıçta sadece bu özel düzenler mevcuttu; donanım tensör sahipliği modellerini doğrudan temsil ediyor ve yaygın durumlar için yeterliydi. Ancak, kernel'ler karmaşıklaştıkça ve optimizasyonlar arttıkça, eksiklikleri belirginleşti. Her özel düzenin kendine ait bir tanımı ve mekanizması olduğu için, ttg.convert_layout gibi operasyonlarda farklı kaynak ve hedef düzenler arasında çok sayıda noktadan noktaya dönüşüm senaryosuyla uğraşmak gerekti. Bu durum, kaynak düzen * hedef düzen * veri değişimi gibi kombinasyonel bir problem yaratıyordu ve yönetimi zorlaştırıyordu.
Compiler'ın eleman sahipliğinin kernel kodu boyunca nasıl aktarıldığını anlaması ve hesaplaması, birleşik bir mekanizma olmadan zordu. ttg.convert_layout her ne kadar yerelleşmiş dönüşümler sağlasa da, gereksiz dönüşümlere yol açabiliyordu. Ayrıca, .permute() ve .reshape() gibi şekil manipülasyonu operasyonları kavramsal olarak maliyetsiz olsa da, compiler'ın bunları düzen dönüşümleriyle birlikte optimize edebilmesi için birleşik bir yaklaşıma ihtiyacı vardı. Bu ihtiyaçlar doğrultusunda, genel bir temel olarak lineer düzen tanıtıldı.
Triton compiler'ındaki özel düzenlerin evrimi ve lineer düzenlerin getirdiği genelleştirilmiş optimizasyon yetenekleri, karmaşık kernel'lerin daha verimli işlenmesini sağlıyor.