Aros/開發者/文件/HIDD/Nouveau
NouveauBitMap 類包含一個 nouveau_bo 物件。此物件表示記憶體中一個可從 GPU 訪問的緩衝區（VRAM 或 GART）。此 nouveau_bo 物件用於複製和填充等函式。
Nouveau 需要最小的 64x64 畫素塊大小才能使用加速傳輸。
UAE P96 到目前為止，picasso96 模擬始終使用 RGBFF_CHUNKY，它對映到 cybegraphics 中的 PIXFMT_BGR15，並透過 WirtePixelArray 將內容複製到顯示視窗。當使用 WritePixelArray 時，會進行模式之間的轉換。我根據其他驅動程式進行了此轉換，因此此處不應有差異。現在它嘗試透過 GetCyberIDAttr(modeID, CYBRIDATTR_PIXFMT) 獲取畫素格式，因此不應需要格式轉換。從 PIXFMT_BGR15 到 24 位的轉換不應該那麼慢。此外，WritePixelArray 現在已加速，因此應該非常快。
當 3D 驅動程式想要將渲染緩衝區blit到點陣圖上時，它需要獲取點陣圖背後的 nouveau_bo 並從其渲染緩衝區到此 nouveau_bo 物件進行 GPU 複製。渲染緩衝區始終與點陣圖具有相同的畫素格式，因為它是在建立 GL 上下文時基於傳遞的點陣圖建立的。
我認為 Amiga 3D API 是 Warp3D，但我對此一無所知。在此上下文中，OpenGL 是一個外來的 API。
是的，mesa.library 是 AROS 特定的。我從未見過或使用過您提到的庫，但我認為 AROSMesa API 可能與 StormMESA API 類似。我基於 Kalamatee 的工作構建了 AROSMesa API，該工作似乎基於 StormMESA。
從客戶端的角度來看，使用 mesa.library 非常簡單
- 建立一個視窗
- 呼叫 AROSMesaCreateContext 並將視窗和其他一些內容傳遞給它 -> 您將獲得作為返回值的渲染上下文
- 呼叫 AROSMesaMakeCurrent 並將上下文傳遞給它，以便 AROSMesa 知道在哪裡渲染
- 使用 glXXX 函式渲染一些內容
- 呼叫 AROSMesaSwapBuffers 將渲染緩衝區的內容繪製到您的視窗上
- 迴圈到 glXXX 函式
如果您正在尋找示例，請檢查 /tests/mesa/mesasimplerendering.c 並檢查 AROSMesaCreateContext() 程式碼。
此函式實際上負責設定“管道螢幕”——一個實際上用於渲染的實體。管道螢幕使用 gallium.library 管理，後者又使用 OOP 物件工作。
想知道在 SDL_Init() 和 SDL_Quit() 中做了什麼；無論如何都不需要 peropenerbase 嗎？嗯。SDL_VideoInit 操作全域性變數“current_video”。但是 MorphOS 的 PowerSDL 似乎也做了同樣的事情。
SDL 是否有一個上下文傳遞給每個函式，或者它是否依賴於上下文是“全域性的”（就像 GL 一樣）。如果是後者，您需要檢查上下文是否可以是每個開啟器（由多個任務共享）或上下文是否需要真正地每個任務。
是後者。我想知道這些問題是否是我的 MorphOS 的 PowerSDL 生成 ThreadServer 任務的原因。
或者，您可以使用我為 Mesa 使用的方法。Mesa 始終透過宏訪問全域性上下文，並且在 AROS 的情況下，此宏實際上使用我自己的非常簡單的實現的“庫端任務本地儲存”。（參見 AROS/workbench/libs/mesa/src/aros/tls.[ch]）。這樣就不需要進行任何 GL API 更改。
目前 gallium.library 只知道兩個後端
hidd.gallium.nouveau and hidd.gallium.softpipe (a software implementation).
此後端列表是硬編碼的。
這裡我看到了兩個設計缺陷
- 後端列表硬編碼。新增第三個後端（例如，用於 ATI）將需要修改 gallium.library。
- 後端物件（表示管道螢幕）在沒有引數的情況下建立。它與任何顯示驅動程式物件無關。
Nouveau 驅動程式的設計方式是在類靜態資料中儲存顯示卡資訊（自動禁止使用多個顯示卡）。這是一個嚴重的缺陷。
為了克服這些問題，我建議做一些類似於點陣圖管理的事情。我會在圖形驅動程式類中新增一個方法，例如 moHidd_Gfx_NewPipeScreen。它將建立一個 hidd.gallium 子類的物件。實際的子類將取決於驅動程式（呼叫該方法的驅動程式）。
如果此方法返回 NULL，則表示此驅動程式不支援硬體加速 3D。在這種情況下，gallium.library 將使用 hidd.gallium.softpipe，就像現在一樣。
gallium.library/CreatePipeScreen()
這種方式需要一個引數，例如 Screen*，或者更好的可能是 ViewPort*。它將從 ViewPort 的點陣圖中獲取顯示驅動程式物件
OOP_Object *drv; OOP_Object *bm = vp->RasInfo->BitMap->Planes[0]; OOP_GetAttr(bm, aHidd_BitMap_GfxHidd, (IPTR *)&drv);
我不認為 moHidd_Gfx_NewPipeScreen 是正確的方法，它應該更像是 moHidd_Gfx_GalliumHiddObject。我現在也不願意進行此更改，因為我不相信我知道 gallium.library 的所有用例。請記住，mesa.library 只是可能的客戶端之一，並且您實際上不需要 Screen、ViewPort 或 BitMap 來使用 GPU。您只需要這些東西，如果您實際上想將渲染blit到 AROS 螢幕上。這就是為什麼 3D 驅動程式與 2D 沒有關聯（就像現在的情況一樣）。
這裡有一個關於在 monitorclass 中實現 MM_Query3DSupport 的答案。我們需要新增 moHidd_Gfx_QueryHardware3D，並將畫素格式物件作為引數。驅動程式將能夠檢查給定的畫素格式並確定它是否支援硬體 3D。
對於 nouveau，moHidd_Gfx_QueryHardware3D 的實現應該是
if (card >= NV30 and bitsperpixelofmode >=16) return TRUE; else return FALSE;
我假設您將對 MM_Query3DSupport 進行以下實現
if (moHidd_Gfx_Query3DSupport) return MSQUERY3D_HWDRIVER; else if (bitsperpixelofmode >= 16) return MSQUERY3D_SWDRIVER; else return MSQUERY3D_NODRIVER;
在 monitorclass 中實現 MM_Query3DSupport 的答案。我們需要新增 moHidd_Gfx_QueryHardware3D，並將畫素格式物件作為引數。驅動程式將能夠檢查給定的畫素格式並確定它是否支援硬體 3D。我看到 softpipe.hidd 可以使用任何畫素格式，因此我們可以安全地假設軟體 3D 可以使用任何內容。
我看到 softpipe.hidd 可以使用任何畫素格式，因此我們可以安全地假設軟體 3D 可以使用任何內容。任何大於等於 16 位的內容。Mesa 不支援 256 色渲染。
您對此有何看法？如果可以，我將在規範中新增這些方法。您可以新增 moHidd_Gfx_QueryHardware3D，但我需要時間來考慮您提到的第一個方法。此外，第一個方法目前不需要用於您在 monitorclass 上的工作。
作為任何 HW GFX 驅動程式，Nouveau 目前只能與一張顯示卡一起工作。它是“舊式”驅動程式:) 實際上 CreatePipeScreen 結構 TagItem * 作為引數。這是有意為之，以便在“將來”透過建立額外的標籤並新增它們的處理來實現您描述的內容。我想做一些與您描述非常相似的事情——CreatePipeScreen 將需要傳遞一個 BitMap 來建立合適的管道螢幕——我只是沒有實現它。還要注意：這不會神奇地使 nouveau 支援多張顯示卡，而是在未來支援的更改。
訊號量保護是在呼叫方級別完成的——例如 CopyBox 或 FillRect。我還向程式碼添加了明確的通知
AROS/workbench/hidds/hidd.nouveau/nouveau.conf AROS/workbench/hidds/hidd.nouveau/nouveau_intern.h AROS/workbench/hidds/hidd.nouveau/nouveaubitmapclass.c AROS/workbench/hidds/hidd.nouveau/nouveauclass.c AROS/workbench/hidds/hidd.nouveau/nouveaugalliumclass.c AROS/workbench/hidds/hidd.nouveau/nv04_accel.c AROS/workbench/hidds/hidd.nouveau/nv50_accel.c
/* NOTE: Assumes lock on bitmap is already made */
/* NOTE: Assumes buffer is not mapped */
BOOL HIDDNouveauNV04FillSolidRect(struct CardData * carddata,
struct HIDDNouveauBitMapData * bmdata, ULONG minX, ULONG minY, ULONG maxX, ULONG maxY, ULONG drawmode, ULONG color)
如果像carddata->chan這樣的東西是全域性的（在點陣圖之間共享），那麼僅僅使用點陣圖鎖是不夠的。一個作用於點陣圖A的圖形函式可能與作用於點陣圖B的圖形函式同時發生。
drm層本身負責同步對chan物件的訪問。此外，命令緩衝區是針對每個呼叫者分配和執行的。對映/取消對映是關於獲取緩衝區的VRAM地址。緩衝區分配在VRAM的某個位置，但根據需要，drm層可以將其移動到其他位置。為了獲得緩衝區的“訪問指標”，需要將其對映（nouveau_bo_map）。當緩衝區被對映時，它不能被移動，但加速函式也不能在對映的緩衝區上工作——因此，對於“指標”訪問，我需要對映緩衝區，而對於加速訪問，我需要取消對映它。
在其他地方，例如Linux/X11，情況有所不同，因為X11渲染函式僅由單個任務（X伺服器）執行，但基本上移動Wanderer視窗，例如在mplayer中播放電影或在OWB中重新載入網頁，應該會導致命令緩衝區損壞和GPU掛起或圖形損壞（在最佳情況下）。
請注意，大多數視窗都是簡單的重新整理視窗。這些視窗沒有任何離屏點陣圖。渲染到這些視窗的可見區域直接進入螢幕點陣圖。渲染到這些視窗的隱藏區域將被忽略。
因此，大部分渲染都進入單個位圖：螢幕點陣圖。
OWB可能主要使用RAM中的畫素緩衝區，但沒有點陣圖。
您需要編寫一些測試程式，在智慧重新整理視窗中執行一些RectFill()操作（或驅動程式加速的其他函式）。然後多次執行它，並使某些視窗完全或部分隱藏（渲染到智慧重新整理視窗的可見部分也直接進入螢幕點陣圖。只有渲染到隱藏部分才會進入離屏點陣圖）。Shell（CON:）視窗目前是智慧重新整理視窗（理論上，如果支援字元對映，它們最好是簡單重新整理）。圖層中的一些東西最佳化得很差（導致比真正需要的更多來回blitting），儘管如此。也許您指的是帶有超級點陣圖的視窗/圖層？這些肯定已損壞，但也幾乎毫無用處。
BM_OBJ|COLMAP|COLMOD交換是否始終執行真的重要嗎？在那個（不需要的）“NoFrameBuffer”出現之前的時代，至少它沒有那麼重要，因為如果HIDD_Gfx_Show返回與輸入相同的點陣圖，則交換實際上不會交換任何東西，因為它放置了與已經存在的值相同的值。它似乎以某種方式很重要。Nouveau是NoFrameBuffer驅動程式，如果我返回接收到的點陣圖，第三次解析度更改以某種方式導致問題（崩潰或未重新整理顯示）。我無法追蹤原因，只是不進行交換可以使事情正常工作。
是否有人知道為什麼來自這些測試的過程沒有與我們的HIDD系統整合？特別是現在有了基於GART的nouveau傳輸，它們提供了相當不錯的提升？原因是，如果graphics.hidd位於“ROM”中（這是否屬實似乎每隔幾年就會改變一次），如果添加了所有轉換的真正最佳化版本，它可能會增加相當大的尺寸。即使補丁rgbconv中的那些確實可以提高速度，它們也不是真正最佳化的。最佳化意味著諸如迴圈展開、儘可能使用SSE或類似技術、使用匯編等。此外，對於目標顏色格式的每個RGB位數多於源顏色格式的情況，人們可能希望有一個選項可以選擇快速轉換和更準確的轉換（例如“快速”：R5G5B5 -> R8G8B8 == RRRRR000GGGGG000BBBBB000。== 畫素變暗，因為0填充）== 甚至更多的轉換函式並佔用空間。透過允許在執行時修補轉換函式，還可以更快地編寫、編譯和檢查新例程（patchrgbconv可以選擇基準測試並驗證例程是否按預期工作）。並且也可以由外部編碼人員完成。