<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>Komentáře: Pracovní stanice, IBM PC, Silicon Graphics a začátky 3D (díl 2.)</title>
	<atom:link href="https://notebookblog.cz/technika/historie-technika/pracovni-stanice-ibm-pc-silicon-graphics-a-zacatky-3d-dil-2/feed/" rel="self" type="application/rss+xml" />
	<link>https://notebookblog.cz/technika/historie-technika/pracovni-stanice-ibm-pc-silicon-graphics-a-zacatky-3d-dil-2/</link>
	<description>/ Postřehy a zkušenosti ze světa mobilní techniky</description>
	<lastBuildDate>Fri, 24 Apr 2026 06:34:31 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=4.1.42</generator>
	<item>
		<title>Od: swarm</title>
		<link>https://notebookblog.cz/technika/historie-technika/pracovni-stanice-ibm-pc-silicon-graphics-a-zacatky-3d-dil-2/#comment-237336</link>
		<dc:creator><![CDATA[swarm]]></dc:creator>
		<pubDate>Tue, 01 Jan 2019 12:18:10 +0000</pubDate>
		<guid isPermaLink="false">http://notebookblog.cz/?p=6427#comment-237336</guid>
		<description><![CDATA[[1] ... http://www.futuretech.blinkenlights.nl/i2sec4.html#4.1 &lt;-- tady máš stejnou grafiku v Indigo2. Evidentně je všechno řešeno v CPU až na samotné vykreslení spanu v rámci řádku. Na kreslení spanů je tam nicméně dle dokumentace podpora DMA, takže to nejspíš nemusíš krmit po řádku, ale dáš tam všechny spočítané řádky trojúhelníku najednou a REX3 (který řeší i přímo komunikaci s počítačem) si ho postupně přechroupe za cenu jediného kernel callu.

--

Ještě bych měl dodat, že 3D akcelerátory pro PC pak byly přece jen sofistikovanější. V programátorské dokumentaci originální S3 Virge je vidět, že stačí zadat trojúhelník pomocí předpočítaných slope dat hraničních přímek transformovaného trojúhelníku jako start a delta parametry pro X, Y, Z, případně ještě A pro alpha a U, V, W pro textury. Ta Virge je lepší, než jsem si myslel.]]></description>
		<content:encoded><![CDATA[<p>[1] &#8230; <a href="http://www.futuretech.blinkenlights.nl/i2sec4.html#4.1" rel="nofollow">http://www.futuretech.blinkenlights.nl/i2sec4.html#4.1</a> &lt;&#8211; tady máš stejnou grafiku v Indigo2. Evidentně je všechno řešeno v CPU až na samotné vykreslení spanu v rámci řádku. Na kreslení spanů je tam nicméně dle dokumentace podpora DMA, takže to nejspíš nemusíš krmit po řádku, ale dáš tam všechny spočítané řádky trojúhelníku najednou a REX3 (který řeší i přímo komunikaci s počítačem) si ho postupně přechroupe za cenu jediného kernel callu.</p>
<p>&#8212;</p>
<p>Ještě bych měl dodat, že 3D akcelerátory pro PC pak byly přece jen sofistikovanější. V programátorské dokumentaci originální S3 Virge je vidět, že stačí zadat trojúhelník pomocí předpočítaných slope dat hraničních přímek transformovaného trojúhelníku jako start a delta parametry pro X, Y, Z, případně ještě A pro alpha a U, V, W pro textury. Ta Virge je lepší, než jsem si myslel.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Od: swarm</title>
		<link>https://notebookblog.cz/technika/historie-technika/pracovni-stanice-ibm-pc-silicon-graphics-a-zacatky-3d-dil-2/#comment-237276</link>
		<dc:creator><![CDATA[swarm]]></dc:creator>
		<pubDate>Mon, 31 Dec 2018 16:57:14 +0000</pubDate>
		<guid isPermaLink="false">http://notebookblog.cz/?p=6427#comment-237276</guid>
		<description><![CDATA[[1] Pokud to dobře chápu, v případě SGI Indy to funguje tak, že kromě těch souřadnic musíš do grafiky přidat i úplně všechny slope data spočítaná procesorem. V rasterizátoru je pak iterátor, který je schopný trojúhelník vykreslit dávkově jako hromadu spanů (v rámci pozice spanu je jedna souřadnice pro Y a pak ještě dvě X-start a X-end), které sám postupně modifikuje podle slope dat.

U prvních generací spotřebních PC 3D akcelerátorů by to mělo být stejné. Až ty, které se chlubí, že mají &quot;triangle-setup engine&quot;, si slope data počítají samy.

(SGI Indy tyhle věci dělá na grafice v čipu REX3, mrkni na stranu 32: https://honk.sigxcpu.org/doc/Indy/rex3.pdf )]]></description>
		<content:encoded><![CDATA[<p>[1] Pokud to dobře chápu, v případě SGI Indy to funguje tak, že kromě těch souřadnic musíš do grafiky přidat i úplně všechny slope data spočítaná procesorem. V rasterizátoru je pak iterátor, který je schopný trojúhelník vykreslit dávkově jako hromadu spanů (v rámci pozice spanu je jedna souřadnice pro Y a pak ještě dvě X-start a X-end), které sám postupně modifikuje podle slope dat.</p>
<p>U prvních generací spotřebních PC 3D akcelerátorů by to mělo být stejné. Až ty, které se chlubí, že mají &#8222;triangle-setup engine&#8220;, si slope data počítají samy.</p>
<p>(SGI Indy tyhle věci dělá na grafice v čipu REX3, mrkni na stranu 32: <a href="https://honk.sigxcpu.org/doc/Indy/rex3.pdf" rel="nofollow">https://honk.sigxcpu.org/doc/Indy/rex3.pdf</a> )</p>
]]></content:encoded>
	</item>
	<item>
		<title>Od: klusacek</title>
		<link>https://notebookblog.cz/technika/historie-technika/pracovni-stanice-ibm-pc-silicon-graphics-a-zacatky-3d-dil-2/#comment-237262</link>
		<dc:creator><![CDATA[klusacek]]></dc:creator>
		<pubDate>Mon, 31 Dec 2018 14:57:29 +0000</pubDate>
		<guid isPermaLink="false">http://notebookblog.cz/?p=6427#comment-237262</guid>
		<description><![CDATA[Diky za zajimavy clanek a tesim se na pokracovani.

Na obrazku “Figure 6” jsem si povsiml takove pozoruhodnosti: Vypada to, ze Raster Engine provadi algoritmus pro interpolaci usecky jen na barvach a Z-hodnotach v ramci jednoho radku obrazu. Interpolaci usecek, ktere tvori hranici kresleneho trojuhelniku, provadi jeste geometry engine. 

Je to specialita teto architektury, nebo to tak je obecne? Jak to maji akceleratory, ktere nemaji geometry engine, jako treba graficka karta pro SGI Indy? Zil jsem v predstave, ze procesor do ni posle 2D souradnice vrcholu trojuhelniku (a jejich Z-hodnoty a barvy v rozich) a karta provede vsechny interpolace uz sama. Pokud by ale rasterizer byl podobne konstrukce jako u Personal Iris, tak by to znamenalo ze CPU musi spocitat Z-slope a color-slope pro kazdy radek trojuhelniku a poslat rasterizeru seznam hodnot  pro jednotlive radky, ktere se budou kreslit (vcetne krajich bodu v kazdem radku, protoze uz by je beztak musel spocitat).]]></description>
		<content:encoded><![CDATA[<p>Diky za zajimavy clanek a tesim se na pokracovani.</p>
<p>Na obrazku “Figure 6” jsem si povsiml takove pozoruhodnosti: Vypada to, ze Raster Engine provadi algoritmus pro interpolaci usecky jen na barvach a Z-hodnotach v ramci jednoho radku obrazu. Interpolaci usecek, ktere tvori hranici kresleneho trojuhelniku, provadi jeste geometry engine. </p>
<p>Je to specialita teto architektury, nebo to tak je obecne? Jak to maji akceleratory, ktere nemaji geometry engine, jako treba graficka karta pro SGI Indy? Zil jsem v predstave, ze procesor do ni posle 2D souradnice vrcholu trojuhelniku (a jejich Z-hodnoty a barvy v rozich) a karta provede vsechny interpolace uz sama. Pokud by ale rasterizer byl podobne konstrukce jako u Personal Iris, tak by to znamenalo ze CPU musi spocitat Z-slope a color-slope pro kazdy radek trojuhelniku a poslat rasterizeru seznam hodnot  pro jednotlive radky, ktere se budou kreslit (vcetne krajich bodu v kazdem radku, protoze uz by je beztak musel spocitat).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
