ওপেনজিএল> = 3 কেবল ভিবিওর অনুমতি দেয় কেন?


21

আমি দেখতে পেয়েছি যে ওপেনগিএল সংস্করণ 3 এবং তারপরে ক্লায়েন্ট-সাইড রেন্ডারিংয়ের ব্যবহারকে বাদ দেয়। তাত্ক্ষণিক মোডটি মুছে ফেলা হয়েছে, এবং ভার্টেক্স অ্যারেগুলি অবচিত বলে মনে হচ্ছে। পরিবর্তে, যদি আমি সঠিকভাবে বুঝতে পারি তবে ভিবিওগুলিই শীর্ষকোষকে উপস্থাপনের প্রধান উপায়।

আমি যখন সমস্ত কিছু রেন্ডার করার জন্য অভিন্ন পদ্ধতি রাখার পিছনে যুক্তি দেখছি, তখন কি ভিবিও-র ভার্টেক্স অ্যারেগুলিতে কোনও বড় উত্সাহ নেই? আমি ভেবেছিলাম যে ভিবিওগুলিতে সাধারণত 1MB ডেটা যুক্ত বড় বাফার হওয়ার কথা। আমার যদি এমন কোনও দৃশ্য থাকে যাতে খুব ছোট জ্যামিতি থাকে? আমার কাছে প্রচুর নোডের সাথে একটি দৃশ্যের গ্রাফ রয়েছে যার প্রত্যেকটির নিজস্ব ট্রান্সফর্ম প্রয়োজন needs সুতরাং আমার প্রথম প্রশ্নটি হ'ল, যদি আমি ভিবিওগুলিতে স্যুইচ করি তবে এখন আমার দৃশ্যের গ্রাফ অবজেক্টগুলিতে আরও বেশি ওভারহেড থাকবে কারণ প্রতিটি বস্তুর জন্য একটি ভিবিও বরাদ্দ করা দরকার।

আরেকটি উদ্বেগ হ'ল আমি যে জ্যামিতিটি দিচ্ছি তা অত্যন্ত গতিময় হতে পারে। সবচেয়ে খারাপ ক্ষেত্রে, এমন সময়গুলিও হতে পারে যখন কিছু জ্যামিতির কিছু ফ্রেমের জন্য প্রতিটি ফ্রেমে বিরক্তি প্রকাশ করা প্রয়োজন। এই ব্যবহারের ক্ষেত্রে ভিবিও-এর কি ভারটেক্স অ্যারেগুলির চেয়ে খারাপ পারফরম্যান্স হবে, বা ভিজিওগুলি কি ভার্টেক্স অ্যারেগুলির মতো কাজ করবে কিন্তু আরও কিছু করবে না?

সুতরাং, আরও সংক্ষিপ্ত আকারে, আমার প্রশ্নগুলি হ'ল:

1) ভিবিওগুলি বরাদ্দ করা / অবলম্বন করার জন্য কি যথেষ্ট ওভারহেড রয়েছে (আমি বোঝাচ্ছি বাফার স্থাপনের নিছক কাজ)?

2) আমি যদি প্রতিটি ফ্রেমে সিপিইউ থেকে ডেটা আপডেট করে থাকি তবে আমি কি ভারটেক্স অ্যারে ব্যবহার করেছিলাম তার চেয়ে এটি কি আরও খারাপ হতে পারে?

এবং অবশেষে, আমি জানতে চাই:

)) উপরের যে কোনও প্রশ্নের উত্তর যদি "হ্যাঁ" হয় তবে ভিবিওর তুলনায় সুবিধা পেতে পারে এমন অন্যান্য উপস্থাপনের কেন অবনতি করবেন? আমি এখানে কিছু অনুপস্থিত আছে, যেমন কৌশলগুলি যেমন এই সম্ভাব্য বরাদ্দ ব্যয়গুলির কিছুটা প্রশমিত করার জন্য ব্যবহার করার কথা?

৪) আমি যে ওপেনজিএল সংস্করণটি ব্যবহার করছি তার উপর নির্ভর করে এই প্রশ্নের যে কোনও প্রশ্নের উত্তর কি যথেষ্ট পরিবর্তন হয়? আমি যদি আমার কোডটি ওপিজএল 3 বা 4 ফরোয়ার্ড-সামঞ্জস্যপূর্ণ হিসাবে VBOs ব্যবহার করে এমনভাবে উপস্থাপনযোগ্য হিসাবে ব্যবহার করি তবে একই কৌশলগুলি ওপেনজিএল 2 এর সাথে আরও ভাল পারফর্ম করতে পারে, বা সম্ভবত কিছু কৌশল ওপেনজিএল 3 এর সাথে আরও দ্রুততর হয় ওপেনজিএল 2 সহ আরও কি?

আমি স্ট্যাক ওভারফ্লোতে এই প্রশ্নটি জিজ্ঞাসা করেছি, তবে আমি এখানে পুনরায় পোস্ট করছি কারণ আমি বুঝতে পেরেছিলাম যে এই সাইটটি আমার প্রশ্নের জন্য আরও উপযুক্ত হতে পারে।


1
কেন ভোট বন্ধ হবে? এটা কি বোকা? যদি তা হয় তবে আমি কি একটি লিঙ্ক দেখতে পাচ্ছি যাতে আমি এটি থেকে উপকৃত হতে পারি?
মাধ্যাকর্ষণ

উত্তর:


23

ভিবিওগুলি বরাদ্দ করা / অবলম্বন করার জন্য কি যথেষ্ট ওভারহেড রয়েছে (আমি বাফার স্থাপনের নিছক কাজ)?

"যথেষ্ট" সংজ্ঞা দিন। এগুলি ফ্রেমের মাঝে তৈরি না করা সাধারণত বুদ্ধিমানের কাজ; সেগুলি সূচনা করার সময় বা যেখানেই হোক সেটআপ করা উচিত। তবে টেক্সচার, রেন্ডারবুফার বা শেডারগুলির মতো বেশিরভাগ ওপেনজিএল অবজেক্টের ক্ষেত্রে এটি সত্য।

আমি যদি প্রতিটি ফ্রেমে সিপিইউ থেকে ডেটা আপডেট করে দিই, তবে আমি যদি ভার্টেক্স অ্যারে ব্যবহার করেছিলাম তার চেয়ে এটি কি আরও খারাপ হতে পারে?

পারি এটা? হ্যাঁ। ওপেনজিএল কার্যকারিতা সংজ্ঞা দেয়, কর্মক্ষমতা নয় । আপনি প্রকৃতপক্ষে জিনিসগুলিকে অনেক ধীর করতে পারেন। অথবা আপনি জিনিসগুলি আরও দ্রুত তৈরি করতে পারেন। এটি আপনি কীভাবে ব্যবহার করেন তার উপর নির্ভর করে।

কীভাবে ডেটা সঠিকভাবে স্ট্রিম করা যায় সে সম্পর্কে ওপেনজিএল উইকির একটি ভাল নিবন্ধ রয়েছে

উপরের যে কোনও প্রশ্নের উত্তর যদি "হ্যাঁ" হয় তবে ভিবিওর চেয়ে সুবিধা পেতে পারে এমন অন্যান্য উপস্থাপনের কেন অবনতি করবেন? আমি এখানে কিছু অনুপস্থিত আছে, যেমন কৌশলগুলি যেমন এই সম্ভাব্য বরাদ্দ ব্যয়গুলির কিছুটা প্রশমিত করার জন্য ব্যবহার করার কথা?

প্রথমত, তাদের কেবল অবমূল্যায়ন করা হয়নি। অবমূল্যায়ন মানে ভবিষ্যতের সংস্করণগুলিতে কিছু "মুছে ফেলা" হিসাবে চিহ্নিত করা। এগুলিকে 3.0 এ অবমূল্যায়ন করা হয়েছিল এবং 3.1 কোর এবং তারপরে উপরে সরানো হয়েছিল।

দ্বিতীয়ত, এআরবি সাধারণভাবে ওপেনজিএল থেকে জিনিসগুলি সরিয়ে দেওয়ার কারণ ব্যাখ্যা করেছে। এটি স্পেকটিকে আরও ছোট এবং সহজ করে তোলে। এটি এপিআইকে আরও ছোট এবং আরও প্রবাহিত করে। আপনার কোন API গুলি ব্যবহার করা উচিত তা জানা সহজ করে তোলে; ২.১ এর ভার্টেক্স তথ্য সরবরাহের 4 টি উপায় ছিল; 3.1+ এর রয়েছে 1. এটি প্রচুর ক্রাফ্ট থেকে মুক্তি পায়। প্রভৃতি

আমি যে ওপেনজিএল সংস্করণটি ব্যবহার করছি তার উপর নির্ভর করে এই প্রশ্নের যে কোনও প্রশ্নের উত্তর কি যথেষ্ট পরিবর্তন হয়? আমি যদি আমার কোডটি ওপিজএল 3 বা 4 ফরোয়ার্ড-সামঞ্জস্যপূর্ণ হিসাবে VBOs ব্যবহার করে এমনভাবে উপস্থাপনযোগ্য হিসাবে ব্যবহার করি তবে একই কৌশলগুলি ওপেনজিএল 2 এর সাথে আরও ভাল পারফর্ম করতে পারে, বা সম্ভবত কিছু কৌশল ওপেনজিএল 3 এর সাথে আরও দ্রুততর হয় ওপেনজিএল 2 সহ আরও কি?

কম-বেশি না। কেবলমাত্র ম্যাকোএসএক্স-এ 3.1 + কোর এবং প্রাক-3.0 সংস্করণগুলির মধ্যে পার্থক্যটি সত্যই আপাতভাবে দেখা যায়। সামঞ্জস্যতা প্রোফাইলটি লিনাক্স এবং উইন্ডোজের জন্য সমস্ত ড্রাইভার দ্বারা প্রয়োগ করা হয়েছে, সুতরাং আপনি ধরে নিতে পারেন যে এই ড্রাইভারগুলির মূল প্রোফাইলটি আপনাকে সামঞ্জস্যতা ফাংশনগুলি কল করতে বাধা দেওয়ার জন্য কেবলমাত্র চেক যোগ করছে।

অধীনে ম্যাক ওএসএক্স 10.7, gl 3.2 কোর পাওয়া যাচ্ছে, কিন্তু না সামঞ্জস্য প্রোফাইল। এটি অপরটির বিপরীতে পারফরম্যান্স কৌশলগুলির জন্য অগত্যা কোনও অর্থ নয় । তবে এর অর্থ এই নয় যে যদি পার্থক্য থাকে তবে সেই প্ল্যাটফর্মটি আপনি তাদের দেখতে পাবেন।


1
যেহেতু আপনি কেবল এই প্রশ্নটি ক্রস পোস্ট করেছেন , আমি কেবল আমার উত্তর ক্রস পোস্ট করব।
নিকল বোলাস

এপিআই সংক্ষিপ্ত রাখার আরেকটি সুবিধা হ'ল এটি ওপেনজিএল এপিআই কার্যকর করা সহজ করে তোলে। এটি মূল ওপেনজিএল ইএস অনুমানের ক্ষেত্রে একটি বড় বিবেচ্য বিষয় ছিল।
জানুন

@ স্টেফেল্টন: বুদ্ধি তৈরি করে। আমার "ভিবিও ব্যতীত কেন সমস্ত কিছু হ্রাস করা হবে" প্রশ্নটি এই চিন্তার উপর ভিত্তি করে তৈরি হয়েছিল যে এটি এপিআই হেলান রাখতে যথাযথ বুদ্ধি বোধ করার পরেও অনেকগুলি ব্যবহারের ক্ষেত্রে ভিবিওর চেয়ে ভাল হতে পারে এমন বৈশিষ্ট্যগুলি হ্রাস করা বোধগম্য নয়। আমি যা শুনছি তা থেকে মনে হচ্ছে ভিবিওগুলি ব্যবহারের কোনও অসুবিধা নেই, তবে, তারপর সমস্ত কিছু হ্রাস করার উপযুক্ত ধারণাটি তৈরি করে।
মাধ্যাকর্ষণ

@gravity আপনি না আছে VBO এর ব্যবহার করতে। আপনি পাশাপাশি শিখুনের একটি অ্যারে ব্যবহার করতে পারেন।
notlesh

18

ওপেনজিএল যেভাবে কাজ করে, যখনই আপনি নন-ভিবিও ডেটা ব্যবহার করেন, চালককে এটির একটি অনুলিপি তৈরি করতে হবে - একটি অস্থায়ী ভিবিও তৈরির অনুশীলনে - যেহেতু কোনও কিছুই আপনাকে ওপেনগিএলের কলগুলির মধ্যে আপনার ব্যবহারকারী-স্থান নগ্ন অ্যারেগুলিকে সংশোধন থেকে বিরত রাখে না।

টেম্পের বরাদ্দ দ্রুত করার জন্য কিছু চালক-পক্ষের কৌশল থাকতে পারে তবে অনুলিপি এড়ানোর জন্য আপনার কিছুই করার নেই।

হ্যাঁ, যতক্ষণ না আপনি - এবং ড্রাইভার বিকাশকারীগণ - যতক্ষণ না সবকিছু ঠিকঠাক করুন, ভিবিওগুলিকে সর্বদা কেবল জিনিসগুলি দ্রুত করা উচিত।


6
আমি এই উত্তরটি আরও ভাল পছন্দ করি। এটি সংক্ষিপ্ত এবং আরও নীচে, ইমো।
ট্র্যাভিসজি

@ জারিকম্প্পা: এটি খুব যুক্তিসঙ্গত ব্যাখ্যা বলে মনে হচ্ছে। আমার এখনও একটি উদ্বেগ রয়েছে: ভিবিওগুলিকে যুক্তিসঙ্গতভাবে বড় আকারের বস্তু বলে মনে করা হয়, প্রায়শই 1MB হিসাবে বরাদ্দ করা হয় - 4MB বাফার শেষবার যাচাই করেছিলাম। আমার জ্যামিতি অবজেক্টগুলি যদি এত বড় না হয় তবে আমার প্রচুর অবজেক্ট রয়েছে বলে আমি এখনও কর্মক্ষমতা নিয়ে উদ্বিগ্ন? আমি ভীত, আমার কাছে যা আছে তার চেয়ে ভিবিওগুলি কেবল অন্য ব্যবহারের ক্ষেত্রে হতে পারে। আমি কি একক ভিবিওতে এক সাথে একাধিক অবজেক্ট পুল করব এবং তারপরে glDrawRangeElementsপ্রতিটি স্বতন্ত্র বস্তু আঁকতে ব্যবহার করব , বা ভার্টেক্স অ্যারেগুলির মতো এটি কী অক্ষম?
মাধ্যাকর্ষণ

আমি সন্দেহ করি যে এটি কোনও পার্থক্য আনবে, তবে আপনি যদি এটি উদ্বেগ বোধ করেন তবে এটি বেঞ্চমার্ক করুন।
জারি কম্প্পা

@ জারিকম্প্পা: আপনি কী সন্দেহ করছেন যে একটি পার্থক্য আনবে? glDrawRangeElementsপ্রতিটি ভিবিওতে একাধিকবার কয়েকটি ভিবিও দিয়ে প্রতিটি আইটেমকে তার নিজস্ব ভিবিও দেওয়ার চেয়ে একাধিকবার ব্যবহার করা হয় ?
মাধ্যাকর্ষণ

1
যথাযথভাবে। আমি সন্দেহ করি আপনি সেখানে অনেক পার্থক্য দেখতে পাবেন, তবে কিছু পরীক্ষার ক্ষেত্রে প্রোফাইল দেওয়ার ক্ষেত্রে আপনাকে আরও তথ্য দেওয়া উচিত। আমি এখনই এটি নিয়ে চিন্তিত হব না, কারণ এর মতো পরিবর্তনটি পরে প্রয়োজনে প্রয়োগ করা যেতে পারে।
জারি কম্প্পা

9

এবং ভার্টেক্স অ্যারেগুলি অবচিত বলে মনে হচ্ছে। পরিবর্তে, যদি আমি সঠিকভাবে বুঝতে পারি,

বেশ না। ভার্টেক্স অ্যারেগুলি ভার্টেক্স বাফার অবজেক্টের ভিত্তি। কেবল স্টোরেজ ক্লায়েন্ট থেকে সার্ভারের দিকে চলে গেছে।

আমার যদি এমন কোনও দৃশ্য থাকে যাতে খুব ছোট জ্যামিতি থাকে?

ছোট জ্যামিতি সেট বৃহত্তর ভিবিওগুলিতে মার্জ করুন। জ্যামিতি ব্যাচে প্রতি একটি ভিবিও থাকার দরকার নেই। রেন্ডারিংয়ের জন্য আপনি কোনও ভিবিওর সাবসেটগুলি নিখুঁতভাবে সম্বোধন করতে পারেন। গ্ল… পয়েন্টার ডেটা প্যারামিটারের জন্য একটি ননজেরিও অফসেট ব্যবহার করুন।

2) আমি যদি প্রতিটি ফ্রেমে সিপিইউ থেকে ডেটা আপডেট করে থাকি তবে আমি কি ভারটেক্স অ্যারে ব্যবহার করেছিলাম তার চেয়ে এটি কি আরও খারাপ হতে পারে?

এর জন্য এখানে GL_DYNAMIC_DRAW এবং GL_STREAM_DRAW বাফার ব্যবহারের পতাকা রয়েছে।

উপরের যে কোনও প্রশ্নের উত্তর যদি "হ্যাঁ" হয় তবে ভিবিওর চেয়ে সুবিধা পেতে পারে এমন অন্যান্য উপস্থাপনের কেন অবনতি করবেন?

কারণ কোনও সুবিধা নেই। জ্যামিতির তথ্য যে কোনও ক্ষেত্রে জিপিইউতে স্থানান্তর করতে হবে। একটি নিয়মিত ক্লায়েন্ট সাইড ভার্টেক্স অ্যারে ব্যবহারের পরেও জিপিইউতে একটি ডিএমএ স্থানান্তর ঘটবে এবং তাত্ক্ষণিক মোড প্রথমে স্থানান্তর করার জন্য একটি ব্যাচ তৈরি করবে।

ভিবিও ব্যবহার না করার কোনও লাভ নেই।


সুতরাং আমার পারফরম্যান্সটি সাধারণত ভারটেক্স অ্যারেগুলির তুলনায় ভিবিওগুলির সাথে খারাপ হওয়া উচিত নয়, তবে কেবল আমি যদি সঠিকভাবে মোডটি GL_STREAM_DRAW এ সেট করি?
মাধ্যাকর্ষণ

@ গ্র্যাভিটি: আসলেই। তবে বাফার মোডটি প্রত্যাশিত ব্যবহারের উপর কেবল একটি ইঙ্গিত, তবে অবশ্যই আপনি যা করতে যাচ্ছেন সে বিষয়ে ইঙ্গিতটি সত্য হওয়া উচিত। এছাড়াও ভুলে যাবেন না যে আপনি আপডেটগুলির জন্য আপনার প্রক্রিয়া ঠিকানা স্থানে বাফারগুলি ম্যাপ করতে পারেন (glMapBuffer, glUnmapBuffer)।
ডেটনওল্ফ

তবে বাফারটি ভিআরএমে থাকতে পারে না, তাই না? অথবা এটি এখনও ভিআরএমে থাকবে তবে প্রক্রিয়া-স্থান ঠিকানাগুলির মাধ্যমে কেবল ঠিকানাযোগ্য? এই কৌশলটি দিয়ে এলোমেলো অ্যাক্সেস কি সস্তা হবে, বা এখনও আমি কি খুব কম সংখ্যক নিয়মিত রেঞ্জ আপডেট করার চেষ্টা করব?
মাধ্যাকর্ষণ

@ গ্র্যাভিটি: একটি বাফার কেবল পাঠযোগ্য, কেবল লিখতে বা লেখা পড়তে ম্যাপ করা যায়। আপডেটের জন্য আপনি কেবল লিখতে পছন্দ করবেন। এখন এটি জেনে রাখা গুরুত্বপূর্ণ যে আধুনিক ওএস ভার্চুয়াল ঠিকানার স্থানটি কীভাবে পেজড মেমরির মাধ্যমে পরিচালনা করে। কেবল লেখার মানচিত্রের ক্ষেত্রে আপনি একটি ডিএমএ ট্রান্সফার মেমরির টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো করে লিখেছেন এবং আপনার ম্যাপ করা পরিসীমাটিতে আপনার লেখাগুলি কমবেশি সরাসরি জিপিইউ মেমরিতে চলে যাবে (বিষয়বস্তুগুলি প্রথমে সিপিইউ র‍্যামে লেখা হয়, তবে ডিএমএ দ্বারা জিপিইউতে স্থানান্তরিত হয়) ট্রান্সফার)। ডেটা ক্লায়েন্টের পাশের মেরুদণ্ডের অ্যারের মধ্য দিয়ে গেলে এটি আরও বেশি সরল পথ এটি গুরুত্বপূর্ণ: নিয়মিত প্রক্রিয়া মেমরি
ডিএমএর
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.