<div dir="auto">Those are all valid reasons, but I don't wanna expose swrast for AMD's customers.<div dir="auto"><br></div><div dir="auto">Marek</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 27, 2019, 5:45 AM Mathias Fröhlich <<a href="mailto:Mathias.Froehlich@gmx.net">Mathias.Froehlich@gmx.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marek,<br>
<br>
On Wednesday, 24 April 2019 02:01:42 CEST Marek Olšák wrote:<br>
> Adam, did you notice my original suggestion "If there is at least 1 drm<br>
> device, swrast won't be in the list."? which means swrast would be in the<br>
> list for your "dumb" GPUs.<br>
<br>
Imagine a box with a low end drm capable hardware chip like you find sometimes<br>
in server type boxes (intel/matrox...). Otherwise the box is equipped with lots of cpu<br>
power. This is something that you will find a lot in that major engineering application<br>
environment. Your application will be glad to find the swrast renderer that is finally<br>
more capable than the 'GPU' mostly there to drive an administration console.<br>
You do not want to lock a swrast 'device' (or however you want to call it) out by<br>
a may be less capable 'console GPU'.<br>
<br>
Beside that having a second type of 'normalized renderer' like Eric was telling<br>
about is an other one.<br>
<br>
As well as sometimes it may make sense to utilize the GPU<br>
with one set of work and a second GPU with an other set of work in parallel.<br>
When you only find a single gpu device in one box, you may be glad to find<br>
a swrast device that you can make use of in parallel with the gpu without the need<br>
to put up different code paths in your application.<br>
<br>
May be I can come up with other cases, but thats the 5 minutes for now ...<br>
<br>
best<br>
<br>
Mathias<br>
<br>
<br>
</blockquote></div>