<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
Trying to combine two OpenGL implementations it's technically difficult.  Furthermore one might thing combining two implementations gives the best of both, but easily gives the worst of both worlds, because there's overhead moving data between them.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
Image the worst case scenario: draw on driver A, copy data to driver B, draw on driver B, copy data to driver A.  One might devise a heuristic to avoid switching so often, but the end result would end being the bulk of the rendering beind done on the most capable
 drvier (llvmpipe in this case), so not much better than always using llvmpipe.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;">This is why technologies like NVIDIA SLI which divide the work across multiple identical GPUs tend to split the work in a granular fashion, like whole frames (GPU
 1 draws frame 2*N, GPU 2 draws frame 2*N + 1).</span><br>
</div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
<span style="font-size:12pt;margin:0px;background-color:rgb(255, 255, 255)" class="ContentPasted0">Furthermore, mixing different implementations easily leads to artifacts, like depth fighting, overlapped geometry or gaps between, because 3D APIs specification
 have somewhat  lax rules about rasterization, and float conversion.</span><br class="ContentPasted0">
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
<span style="font-size:12pt;margin:0px;background-color:rgb(255, 255, 255)" class="ContentPasted0"><br>
</span></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
<span style="font-size:12pt;margin:0px;background-color:rgb(255, 255, 255)" class="ContentPasted0">Honestly, it's more effective to buy a more modern device.</span></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
Jose</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
<span style="font-size:12pt;margin:0px;background-color:rgb(255, 255, 255)"></span><br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)" class="elementToProof">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> mesa-dev <mesa-dev-bounces@lists.freedesktop.org> on behalf of test@profit-grand.ru <test@profit-grand.ru><br>
<b>Sent:</b> Tuesday, November 15, 2022 12:48<br>
<b>To:</b> mesa-dev@lists.freedesktop.org <mesa-dev@lists.freedesktop.org><br>
<b>Subject:</b> LLVM-pipe: most powerful instructions set ;)</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">!! External Email<br>
<br>
First, thanks for saving my day. Software renderer works way faster than<br>
no renderer at all :)<br>
<br>
But there are an "instruction set" which is way faster than the MMX or<br>
SSE sets: it's an existing OpenGL 2.0 driver which is not sufficient in<br>
most cases, because at least 3.0 is required nowadays.<br>
<br>
Of course, it's not literally an instruction set, but a source of<br>
additional computing power for basic operations (assuming advanced<br>
operations are not supported by the GPU, making LLVM-pipe necessary for<br>
such systems).<br>
<br>
So, the actual question is:<br>
<br>
Can LLVM-pipe somehow support (today or in future versions) a "bridge<br>
mode", relying on a different OpenGL driver for basic operations<br>
(supported by some ancient GPU) and closing a gap between that driver<br>
and the required OpenGL version it's usual way, by the state-of-art<br>
software renderer?<br>
<br>
It's also somewhat related to my OGLOED driver idea (see my Github), the<br>
difference is "bridge mode" is local, OGLOED is not. But there are some<br>
diagrams which can help understanding my question :)<br>
<br>
<br>
!! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.<br>
</div>
</span></font></div>
</body>
</html>