Ddl (hlsl) thực sự làm gì?


17

Tôi hơi bối rối. Tài liệu chính thức ( http://msdn.microsoft.com/en-us/l Library / windows / desktop / bb509588 (v = vs85) .aspx ) nói rằng ddx (đầu vào) là dẫn xuất một phần của đầu vào đối với đến "tọa độ không gian màn hình x."

Tính toán của tôi là tốt, nhưng làm thế nào nó có thể cho biết đầu vào đến từ đâu? Nếu tôi truyền cho nó một hàm, tốt, tôi có thể tưởng tượng nó sẽ làm gì, nhưng đạo hàm của một số luôn bằng không ...?

Có phải nó chỉ là một tỷ lệ? Giống như, cái này sẽ được thu nhỏ lại một phần mười kích thước của nó ở khoảng cách này, vì vậy nó sẽ trả về một phần mười? Nhưng sau đó nó không cần đầu vào ...

Ai đó có thể giải thích nhanh về những gì thực sự xảy ra?


2
ddxddylàm phép thuật mà bạn không thể tự làm. Họ có quyền truy cập vào thông tin bổ sung từ đường ống rasterization mà bạn không thể có được từ trong trình đổ bóng pixel. Tôi không chắc chắn chính xác họ sử dụng công thức nào; Tôi đã được tin rằng họ sử dụng một kỹ thuật ước tính, nhưng tôi không biết chắc chắn.
Sean Middleditch

Điều đó thật kỳ lạ, nhưng vẫn còn. Ddx (5) thực sự đại diện cho cái gì? Nếu nó nói .1, tôi nên giải thích điều đó như thế nào? Hay -6?
Richard Rast

1
ddx(5)là loại vô nghĩa. Sử dụng nó với một giá trị đầu vào và điều đó sẽ cung cấp cho bạn đạo hàm của giá trị đó đối với các pixel lân cận trong một khối. Một lần nữa, tôi không biết chính xác nó tính toán các giá trị như thế nào, nhưng yêu cầu đạo hàm của một đầu vào không đầu vào cũng có thể chỉ là hành vi không xác định và tạo ra rác. Xem fgiesen.wordpress.com/2011/07/10/ Khăn để biết thêm thông tin mà tôi có thể cung cấp.
Sean Middleditch

Tôi không chắc chắn nhưng cũng có thể là trình biên dịch HLSL thực sự đang thực hiện phân biệt biểu tượng đầy đủ của biểu thức mà bạn truyền cho ddx / ddy. blogs.msdn.com/b/chuckw/archive/2011/03/08/... research.microsoft.com/pubs/146019/...
Ziriax

Nó làm gì? Điều CHỈ hơi hợp lý, rõ ràng.
MickLH

Câu trả lời:


32

Trong nội bộ, GPU không bao giờ chạy một phiên bản của trình đổ bóng pixel tại một thời điểm. Ở mức độ chi tiết tốt nhất, chúng luôn chạy 32-64 pixel cùng lúc bằng kiến ​​trúc SIMD. Trong phạm vi này, các pixel được tổ chức thành các hình tứ giác 2x2, do đó, mỗi nhóm 4 pixel liên tiếp trong vectơ SIMD tương ứng với một khối pixel 2x2 trên màn hình.

Đạo hàm được tính bằng cách lấy sự khác biệt giữa các pixel trong một hình tứ giác. Chẳng hạn, ddxsẽ trừ các giá trị trong các pixel ở phía bên trái của quad khỏi các giá trị ở phía bên phải và ddysẽ trừ các pixel phía dưới khỏi các pixel trên cùng. Sự khác biệt sau đó có thể được trả về dưới dạng đạo hàm cho cả bốn pixel trong bộ tứ.

Vì trình đổ bóng pixel đang chạy trong SIMD, nên đảm bảo rằng giá trị tương ứng nằm trong cùng một thanh ghi cùng lúc cho tất cả các pixel trong bộ tứ. Vì vậy, bất kỳ biểu thức hoặc giá trị nào bạn đặt vào ddxhoặc ddy, nó sẽ được đánh giá trong cả bốn pixel của hình tứ giác, sau đó các giá trị từ các pixel khác nhau được trừ như mô tả ở trên.

Vì vậy, lấy đạo hàm của một giá trị không đổi sẽ cho số không (như bạn mong đợi từ phép tính, phải không?) Vì đó là cùng một giá trị không đổi trong cả bốn pixel.

Cũng lưu ý rằng có các dẫn xuất "thô" và "tốt", ddx_coarse/ ddy_coarseddx_fine/ ddy_fine. Một lời giải thích về sự khác biệt được đưa ra ở đây . Chỉ đơn giản ddx/ ddylà bí danh cho các phiên bản thô.

BTW, lý do chức năng này tồn tại là các GPU bên trong phải lấy dẫn xuất của tọa độ kết cấu để thực hiện lựa chọn mipmap và lọc bất đẳng hướng. Vì phần cứng dù sao cũng cần khả năng (bạn có thể sử dụng bất kỳ biểu thức tùy ý nào cho tọa độ kết cấu trong trình đổ bóng), nên cũng dễ dàng tiếp xúc trực tiếp với các lập trình viên đổ bóng.


+1; Tôi đã thấy điều này hữu ích khi áp dụng hiệu ứng nhiễu loạn cho kết cấu; các texcoords bị nhiễu đã cho một số biến dạng màu sắc, nhưng sử dụng tex2Dgrad với các dẫn xuất từ ​​các texcoords gốc (không bị xáo trộn) đã cho kết quả không bị biến dạng.
Maximus Minimus

Được rồi, sau một số suy nghĩ tôi nghĩ rằng tôi đã tìm ra sự nhầm lẫn của tôi. Trong tâm trí của tôi, ddxhoạt động như mọi chức năng khác trong ngôn ngữ lập trình truyền thống; bạn đánh giá đầu vào, biến nó thành float hoặc bất cứ điều gì, sau đó thực hiện chức năng bên ngoài ( ddx) cho nó. Nhưng điều này là khác - nó lấy chuỗi đầu vào , đánh giá nó ở một vài nơi, tính toán một đạo hàm và báo cáo kết quả. Điều đó có đúng không?
Richard Rast

1
@RichardRast Phải. Bạn có thể nghĩ về việc ddxvận hành biểu thức bạn truyền vào nó, hơn là giá trị .
Nathan Reed

Nhưng hãy xem, điều đó đủ kỳ lạ mà nó nên có trong tài liệu. Tôi có thể nghĩ rằng không có thời gian khác trong cuộc sống lập trình của tôi, nơi đó đã từng là trường hợp.
Richard Rast

Nathan Reed đã đề cập rằng GPU sử dụng các chức năng này để lựa chọn mipmap. Bạn cũng có thể sử dụng chúng để buộc GPU chọn mức mipmap mong muốn hoặc để ngăn các tạo phẩm từ lựa chọn cấp độ mip không chính xác. Quá trình này được mô tả trên các trang 163 và 164 của Shader X3.
JamesHoux
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.