@Brecht Van Lommel (brecht) uff, sorry, I didn't realize that.
@rob (rob_on_earth) you should remove your last comment, because it is still visible in the edit history.

@ ronsn (ronsn), the point is to report the security issue privately.

• Where,
• when,
• what exactly,
• what are your system specs,
• which version(s),
• screenscots,
• exact steps for other to reproduce this issue

I tried the Victor scene with an unrelated Windows laptop with 16GB ram and it had the same result.

@Sem Mulder (SemMulder) How about this for the Top 50 query:

SELECT rank() OVER (ORDER BY sum(per_benchmark.median_render_time)) AS rank,
       per_benchmark.device_name                                    AS device_name,
       json_object_agg(per_benchmark.benchmark,
                       per_benchmark.median_render_time)            AS median_render_times,
       sum(per_benchmark.number_of_samples)                         AS number_of_samples
FROM (
         SELECT rank() OVER (PARTITION BY per_device_type.device_name, per_device_type.benchmark ORDER BY per_device_type.median_render_time) as rank,*
         FROM (
                  SELECT percentile_cont(0.5)
                         WITHIN GROUP (ORDER BY opendata_main_benchmark.render_time) AS median_render_time,
                         opendata_main_benchmark.device_name                         AS device_name,
                         opendata_main_benchmark.device_type                         AS device_type,
                         opendata_main_benchmark.benchmark                           AS benchmark,
                         count(*)                                                    AS number_of_samples
                  FROM opendata_main_benchmark
                  WHERE opendata_main_benchmark.benchmark IN %(benchmarks)s AND opendata_main_benchmark.device_name NOT IN %(device_name_blacklist)s
                  GROUP BY opendata_main_benchmark.device_name, opendata_main_benchmark.device_type, opendata_main_benchmark.benchmark
                  HAVING count(*) >= %(minimum_number_of_samples_per_benchmark)s
              ) per_device_type
     ) per_benchmark
WHERE per_benchmark.rank = 1
GROUP BY per_benchmark.device_name
HAVING count(per_benchmark.benchmark) = %(number_of_benchmarks)s
ORDER BY rank
LIMIT 50;

This adds one additional step to the query which selects the better device type for a device (see the extra SELECT rank() in there, the rest is pretty much identical to the old query). It will only have an effect on RTX GPUs currently, which support two device types (CUDA and OptiX). But it ensures the median render time is only calculated for the better option instead of calculating it over all device types.

Hmm, this is strange. I am able to reproduce this on a Quadro RTX 5000. I will look into attaching a debugger on Windows.

Yet on the home page, the GeForce RTX 2080 Ti shows 38.63 for the bmw27 scene (which is close to the CUDA number) and the GeForce RTX 2080 SUPER shows 28.94 (which is close to the OptiX number).

I believe @Ray molenkamp (LazyDodo) is correct here. We are currently still investigating how to detect this properly (detecting the amount of GPU memory available across all brands is a bit complicated). Closing this for now as this is not an issue with the launcher per se.

@Sem Mulder (SemMulder) mind having a look at the last remark here?

There is some weird behavior with the results currently displayed on http://opendata.blender.org:

peak memory for victor on my box is 16774.97M that 16GB of ram may be just a little short there.

Yes that would be preferable!

You can still send in results for CUDA on RTX GPUs right now though, in addition to OptiX. It's only that those ideally should not affect the overall rank, since it's the worse option.

Another approach might be to limit the results on the homepage to recent results (e.g. one year).

Implemented in rBODb9b62db1ed307fdbcabcd2ef82d23940589d76c8 and deployed.

This is now live.

Would it not be better to include something in the launcher for this? It would not be that hard to add a button that allows the user to clear the cache.

Closing this for now, feel free to open a new ticket if the problem occurs with the new launcher as well.

I have no idea why am I missing the path variable if it's supposed to be there by default. I haven't removed any from the defaults. This is also a clean Windows 1909 installed on 24/12/2019 and set-up "as new" without any Microsoft account, back-ups or etc.

@Sem Mulder (SemMulder) Hi Sem! Thank you very much for looking into this. I added "C:\windows\system32\wbem\" and "%SystemRoot%\System32\Wbem" to path and it did indeed resolve the issue. The old blender benchmark wasn't working either (version 1.0 beta 2, missing "Start" buttons) and it fixed that one as well!

Looking deeper into this it is likely that a missing %SystemRoot%\System32\Wbem entry in the PATH will break various other stuff on Windows. @Boyan (siegmour) can you add this entry back into you PATH and try again?

It seems to be an issue with the PATH environment variable. Probably hardcoding the path C:\windows\system32\wbem\wmic.exe will resolve this.

Which version of Windows are you using?

Restricting to GPUs of the same kind makes for cleaner benchmark results I think. Otherwise the data is not likely to be all that useful, because in heterogeneous systems you can no longer figure out which device is really driving the results (e.g. in a system with a Turing GPU and a Maxwell GPU, the former will be heavily penalized by the latter). And it would avoid having to change the presentation of the data much, since results can just be collected under new "2/4/...x GPU Name" devices, similar to the CPUs.

I'm open to allowing multiple GPUs. We do need to figure out some stuff though:

• Do we only allow GPUs of the same kind, as you mentioned?
• Do we allow the user to pick the number of cards? (if so, how?)

This is now live.

Looking at the logs corresponding to the error ids it seems that it cannot find the wmic utility (which we use to query the CPU information). Which version of Windows are you using?

The simplest solution would be to query and display the fastest result for a device, instead of taking the median over all the results. But that may not be accurate enough, depending on how stable the results are.