Does this KHR_debug output mean <1ms or 147ms?

Question

I've enabled GL debug logging in my app, and getting messages such as:

GTT mapping a busy miptree BO stalled and took 0,147 ms

Initially I took the numeral to mean a sub-millisecond delay. Since there's a 0 before the comma, I didn't consider the interpretation "147ms", but this page says:

Don’t use commas in decimals.

... so it can't be a decimal fraction either.

So which is the correct interpretation?

Note: I use Ubuntu Linux and my regional settings are as follows:

As you can see, a period is set to used to separate the fractional part of the number.

Doesn't that entirely depend on your language? In german language, for example, a comma would be the correct separator. — BDL, Jul 25 '17 at 19:05
@BDL: Please see my edit. My system is set to use the US region, although I live in Bulgaria, which uses a comma for separating the fractional part. — Stefan Monov, Jul 25 '17 at 19:07
Check the output of the `locale` command on some terminal. I wouldn't trust that setting screen at all, especially when the grayed-out detailed settings still show `bg_BG`. The message you are experiencing comes from mesa, and tracking it down leads to it being generated via `vsnprintf(...,"%.03fms", ..., value_in_milliseconds);`, which means that the locale settings should apply unless your libc is broken. Also note that broken applications might change parts of the locale setting by themselves. — derhass, Jul 25 '17 at 19:20
[`perf_debug("%s a busy \"%s\" BO stalled and took %.03f ms.\n", action, bo->name, elapsed * 1000);`](https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_bufmgr.c#n685) — genpfault, Jul 25 '17 at 19:26
`perf_debug()` (eventually) maps down to [`vsnprintf()`](https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/imports.c#n259) — genpfault, Jul 25 '17 at 19:31
Does [`setlocale(LC_NUMERIC, "POSIX")`](https://stackoverflow.com/a/3458045/44729) work? — genpfault, Jul 25 '17 at 19:33
@genpfault: I tried that setlocale call (right in the beginning of `main()`), but it didn't change anything. — Stefan Monov, Jul 26 '17 at 04:04
@derhass: Thanks, `locale`'s output indeed says `LC_NUMERIC=bg_BG.UTF-8` - that's likely to be the culprit. Now I'd just like to know how to fix it :) — Stefan Monov, Jul 26 '17 at 04:09

score 0 · Answer 1 · answered Jul 25 '17 at 19:41

How a driver decides what decimal mark to use is implementation-defined (all of the debug output messages are implementation-defined). It may follow your locale settings; it may follow something else. As such, there is no way to guarantee how it formats numbers.

It could be either, though if it is intended as a comma rather than a decimal mark, what would the zero mean?

score 0 · Accepted Answer · answered Jul 26 '17 at 05:16

Thanks to derhass' comment I found that locale's output says LC_NUMERIC=bg_BG.UTF-8. I changed the relevant value in /etc/default/locale to en_US.UTF-8and now a period is used, as expected. So it's indeed a sub-millisecond value.

Note: That's the only way I was able to get it fixed. Nothing I did in the KDE settings page (shown in a screenshot in the question) helped.

Does this KHR_debug output mean <1ms or 147ms?

2 Answers2