درباره چند نخي در Direct3D

[khorzu]

سلام
مي خوام يه سيستم لود و آنلود -بافت و مش- پويا پياده كنم و به نظر مياد بايد براي اين كار يه ترد جدا اختصاص بدم .D3D9 به صورت پيش فرض اجازه دستكاري منابع يه دستگاه كه با يه ترد ديگه ساخته شده رو نمي ده البته موقع ساخته شدن دستگاه يه فلگ داره كه اين امكان رو بوجود مياره ولي توي داكيومنت گفته افت پرفورمنس داره . چي كار بايد كرد ؟ در مورد دسته بندي صحنه هم اگر ايده اي داريد لطفا بگيد .
ممنون.

[سپول]

سلام
مي خوام يه سيستم لود و آنلود -بافت و مش- پويا پياده كنم و به نظر مياد بايد براي اين كار يه ترد جدا اختصاص بدم .D3D9 به صورت پيش فرض اجازه دستكاري منابع يه دستگاه كه با يه ترد ديگه ساخته شده رو نمي ده البته موقع ساخته شدن دستگاه يه فلگ داره كه اين امكان رو بوجود مياره ولي توي داكيومنت گفته افت پرفورمنس داره . چي كار بايد كرد ؟ در مورد دسته بندي صحنه هم اگر ايده اي داريد لطفا بگيد .
ممنون.

من در نسخه قبلی موتورم که بر اساس D3d9 بود، یک taskManager ، یک threadManager و یک سری task داشتم که هر Task وظیفه لود کردن تکسچر یا مش رو داشت. اینها وارد taskManager می شد و به یک thread اختصاص داده می شد. عملیات لازم انجام می شه و نتیجه به صورت Async به thread اصلی (در این مورد به resourceManager) بر گردانده می شد ...
در D3d9 و d3d10 نمی شه در thread دیگه object ساخت (امکانش هست ولی به مشکل می خورید). برای اینکه به مشکل directx بر نخورم، ابتدا d3d object رو می ساختم، در thread جدید فایل decompress و لود می شد، بعد بصورت نتیجه به thread اصلی بر میگرده، در thread اصلی تکسچر و مش lock می شه و اطلاعات لود شده رو با یک memcpy توش می ریزید !

که البته این متد در نسخه جدید موتور hmrEngine به کل عوض خواهد شد.

دراین مورد کاربر SeganX هم می تونه کمکت بکنه و تجربه داره.

مورد دیگه اینکه مبحث multi-threaded programming توی موتور بازی مبحث پیچیده و مشکلی هست، و تجربه و راه های صحیح و خطای زیادی می خواد، اصلا debug و کد نویسی آسونی نداره. در واقع آسونترین بخشش همین loading هست.
حواست باشه که کدی که در multi-thread می نویسی اگه خطایی داشته باشه ممکنه روی یک سخت افزار خودش رو نشون نده و روی سخت افزار دیگه crash کنه. کد multi-thread می تونه سرعت رو حتی کمتر از کد معمولی هم بکنه (اگه بد نوشته بشه)

[SeganX]

یکی از بهترین راه کارها همین راهکاری هستش که سپول گفت. یعنی یک TaskManager درست کنی که بتونی به راحتی task های مختلف رو با تعیین اینکه توی چه threadi اجرا بشن بهش بدی. بعدش دیگه می تونی بوسیله این task ها بین threadها ارتباط برقرار کنی. مثلا از یک thread یک task درست کنی و بدی به task manager که بره تو یه thread دیگه اجرا بشه و بعدش منتظر شی تا جوابش بیاد و thread رو ادامه بدی. با یه سری روش ها و با همین taskها هم می تونی device 3d رو thread safe کنی. اما خب موضوع به همین جا ختم نمی شه. زمان بندی thread ها و sync کردنشون خیلی مهم هستش. مثلا فرض کن که توی یه thread داری یه فایل رو decompress می کنی که بریزی توی یه buffer. در همین لحظه در thread اصلی scene manager تصمیم گرفته که اون buffer رو release کنه. توی سایت هم یه پست در این زمینه گذاشتم.
بهت پیشنهاد می کنم فعلا سعی کنی با ساختار موتورهای بازی سازی و بخش های مختلفش آشنا بشی و در این زمینه کسب تجربه کنی. خیلی از موتورهای خوب هستن که multithread نیستن. خود john carmack هم از multithread خیلی خوشش نمیاد.

[khorzu]

ممنون از راهنمایی ها تون .

من یکم بیشتر سرچ کردم و به اینا رسیدم :
1- این مشکل توی D3D10 با تعیین "thread pool" برای منابع حل شده .
2- به نظر میاد چند نخی توی D3D با ایده تسک منجر هم به طور کامل حل نشه چون توی تئوری داریم که نمی شه وقتی یه دستور D3D در حال اجراست دستور دیگه ای از اون رو فراخوانی کرد ؛ نتیجه اینکه نهایتا حتما رندر باید متوقف بشه تا منابع بارگزاری بشند و اینکه در آخر ما حتما سکته زدن تصویر رو توی خروجی داریم . با این حساب به جای پیاده سازی تسک منجر -البته با در نظر نگرفتن مزیت لود و دیکد فایل توی مموری با یه ترد مجزا - میشه نواحی بحرانی رو (هر جایی که توابع API صدا زده می شه) با یه موتکس گلوبال محافظت کرد.(؟) این جوری کار خیلی ساده تر می شه .
3- فلگ D3DCREATE_MULTITHREADED همه نواحی بحرانی رو به ازای هر بار صدا زدن قفل می کنه . توی تست هایی که گزارش شده بود استفاده از این فلگ به طور متوسط پرفرمنس رو تنها حدود 1% کاهش می ده اما به نظرم حداقل تا وقتی از D3DX استفاده می کنیم محافظت دستی از نواحی بحرانی بهینه تر باشه .

در ضمن به چند نخی برای نمایش لودینگ هم نیاز دارم.