Jest to ograniczenie sprzętowe. Moduł cieniujący fragmenty jest częścią programowalnego potoku, ale ostateczna mieszanka kolorów z docelowym buforem (buforami) nie jest w tym momencie programowalna w powszechnie dostępnym / towarowym sprzęcie (można go konfigurować poprzez stany mieszania, ale nie można pisać arbitralnie kod, który zastępuje wbudowane operacje mieszania GPU).
Powód, dla którego sprzęt nie jest do tego przeznaczony, prawdopodobnie wynika z faktu, że procesory graficzne są w dużej mierze równoległe; przetwarzają wiele fragmentów jednocześnie. Niektóre z tych fragmentów mogą ostatecznie oddziaływać ze sobą w obrębie buforów docelowych, ale ze względu na asynchroniczny charakter przetwarzania fragmentów nie można wiedzieć, jak to zrobić po przetworzeniu fragmentu i wyemitowaniu końcowego koloru ... który wygrał zawsze zdarza się deterministycznie.
To, że piksel A będzie za pikselem B w ostatniej klatce, nie oznacza, że piksel A zawsze zakończy przetwarzanie fragmentów i zostanie zapisany w miejscu docelowym przed B, szczególnie w wielu klatkach renderowania. Tak więc wartość odczytana z bufora docelowego podczas przetwarzania piksela B nie zawsze będzie pikselem A - czasami będą to wyraźne wartości.
Podejrzewam więc, że uniemożliwienie odczytu bezpośrednich buforów docelowych podczas etapu fragmentowania ma znacznie więcej wspólnego z powstrzymaniem programisty shadera przed wystrzeleniem się w stopę poprzez uzyskanie potencjalnie niedeterministycznych wyników z tego odczytu niż z jakichkolwiek faktycznych technicznych ograniczeń w tworzeniu etapu mieszania w pełni- programowalny. Dzięki ścisłej kontroli operacji odczytu (na przykład testu głębokości) GPU zapewnia, że operacje wykonywane z wartością odczytu mają pewien sens.
To powiedziawszy, może się również zdarzyć sprawa kosztów / korzyści. Uczynienie tego aspektu potoku GPU programowalnym nieco skomplikowałoby konstrukcję układu, a potrzeba / popyt na odczyty bufora docelowego był stosunkowo niski w porównaniu do innych funkcji.