Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On 03/26/2013 02:00 AM, Marek Olšák wrote: On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com wrote: On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote: Hi everyone, one image is better than a thousand words: ... Hi, I tried your patches and hit a few problems. As first, they do not apply cleanly on master as they are expecting another your patch cso: add constant buffer save/restore feature for postprocessing to be present. But I guess you are aware of that. Yes, I sent the patch to mesa-dev earlier. Second problem is that when I build mesa with HUD on my 32bit virtual machine, HUD works (with 32bit app of course). When I build it on 64bit (both are same uptodate OS openSUSE 12.3), HUD is not working (with 64bit app). I managed to track it down to failed IMM instruction parsing during HUD_create function. It appears that translate_ctx structure in tgsi_text_translate (file src/gallium/auxiliary/tgsi/tgsi_text.c) is not initialized to zeros under my 64bit system, instead ctx.num_immediates is equal to 1 and hence trigger Immediates must be sorted error. Following fixes HUD for me (note that I really don't know if I am not broking something here in regards to mesa): diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 6b97bee..247ec75 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1577,6 +1577,7 @@ tgsi_text_translate( ctx.tokens = tokens; ctx.tokens_cur = tokens; ctx.tokens_end = tokens + num_tokens; + ctx.num_immediates = 0; if (!translate( ctx )) return FALSE; I've sent a fix for this a couple of days ago: http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg36038.html The third issue is that on both 32bit and 64bit build fonts are not displayed in HUD. I see graphs and transparent background rectangles for text but no text is visible. This one I did not yet solve. Your driver must support the I8_UNORM texture format. I think this also may be related to unexpected by some drivers TGSI declaration of vertex shader inputs: DCL IN[0..1] At least r600g expects the separate declaration for each input, though fortunately it still works in this case because parsed declarations of VS inputs aren't really used in r600g. I noticed exactly the same issue (missing text) with my r600-sb branch because it relies on the number of the parsed inputs from r600g's tgsi translator. It's 1 in this case instead of 2, so second input register is considered undefined and optimized away. I suspect that some other drivers may also handle this declaration incorrectly and this may explain the issue. Vadim One last thought, is it intentional when wrong query is entered that hud graph is displayed but empty? Maybe some text like wrong query XXX would be a good hint. I know it is printed on stdout but looking for warnings in chatty apps like openarena is little tricky. Yes, it's intentional. I guess I can at least make it not draw an empty pane. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On 26.03.2013 12:18, Vadim Girlin wrote: On 03/26/2013 02:00 AM, Marek Olšák wrote: On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com wrote: On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote: Hi everyone, one image is better than a thousand words: ... Hi, I tried your patches and hit a few problems. As first, they do not apply cleanly on master as they are expecting another your patch cso: add constant buffer save/restore feature for postprocessing to be present. But I guess you are aware of that. Yes, I sent the patch to mesa-dev earlier. Second problem is that when I build mesa with HUD on my 32bit virtual machine, HUD works (with 32bit app of course). When I build it on 64bit (both are same uptodate OS openSUSE 12.3), HUD is not working (with 64bit app). I managed to track it down to failed IMM instruction parsing during HUD_create function. It appears that translate_ctx structure in tgsi_text_translate (file src/gallium/auxiliary/tgsi/tgsi_text.c) is not initialized to zeros under my 64bit system, instead ctx.num_immediates is equal to 1 and hence trigger Immediates must be sorted error. Following fixes HUD for me (note that I really don't know if I am not broking something here in regards to mesa): diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 6b97bee..247ec75 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1577,6 +1577,7 @@ tgsi_text_translate( ctx.tokens = tokens; ctx.tokens_cur = tokens; ctx.tokens_end = tokens + num_tokens; + ctx.num_immediates = 0; if (!translate( ctx )) return FALSE; I've sent a fix for this a couple of days ago: http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg36038.html The third issue is that on both 32bit and 64bit build fonts are not displayed in HUD. I see graphs and transparent background rectangles for text but no text is visible. This one I did not yet solve. Your driver must support the I8_UNORM texture format. I think this also may be related to unexpected by some drivers TGSI declaration of vertex shader inputs: DCL IN[0..1] But this is in no way invalid, any driver that doesn't handle it is broken. Moreover, ideally, IN/OUT should follow the same array declaration and access semantics as TEMP, that's just not implemented yet because it's a bit more involved (WIP). At least r600g expects the separate declaration for each input, though fortunately it still works in this case because parsed declarations of VS inputs aren't really used in r600g. I noticed exactly the same issue (missing text) with my r600-sb branch because it relies on the number of the parsed inputs from r600g's tgsi translator. It's 1 in this case instead of 2, so second input register is considered undefined and optimized away. I suspect that some other drivers may also handle this declaration incorrectly and this may explain the issue. Vadim One last thought, is it intentional when wrong query is entered that hud graph is displayed but empty? Maybe some text like wrong query XXX would be a good hint. I know it is printed on stdout but looking for warnings in chatty apps like openarena is little tricky. Yes, it's intentional. I guess I can at least make it not draw an empty pane. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On Tuesday 26 of March 2013 15:18:06 Vadim Girlin wrote: On 03/26/2013 02:00 AM, Marek Olšák wrote: On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com wrote: On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote: The third issue is that on both 32bit and 64bit build fonts are not displayed in HUD. I see graphs and transparent background rectangles for text but no text is visible. This one I did not yet solve. Your driver must support the I8_UNORM texture format. I think this also may be related to unexpected by some drivers TGSI declaration of vertex shader inputs: DCL IN[0..1] I can confirm that rewriting it into two separate declarations fixed the font issue for me, using r600 on rv770 hw. At least r600g expects the separate declaration for each input, though fortunately it still works in this case because parsed declarations of VS inputs aren't really used in r600g. I noticed exactly the same issue (missing text) with my r600-sb branch because it relies on the number of the parsed inputs from r600g's tgsi translator. It's 1 in this case instead of 2, so second input register is considered undefined and optimized away. I suspect that some other drivers may also handle this declaration incorrectly and this may explain the issue. Vadim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
I think this should be fixed in drivers. Marek On Tue, Mar 26, 2013 at 7:38 PM, Ondrej Holecek aaa...@gmail.com wrote: On Tuesday 26 of March 2013 15:18:06 Vadim Girlin wrote: On 03/26/2013 02:00 AM, Marek Olšák wrote: On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com wrote: On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote: The third issue is that on both 32bit and 64bit build fonts are not displayed in HUD. I see graphs and transparent background rectangles for text but no text is visible. This one I did not yet solve. Your driver must support the I8_UNORM texture format. I think this also may be related to unexpected by some drivers TGSI declaration of vertex shader inputs: DCL IN[0..1] I can confirm that rewriting it into two separate declarations fixed the font issue for me, using r600 on rv770 hw. At least r600g expects the separate declaration for each input, though fortunately it still works in this case because parsed declarations of VS inputs aren't really used in r600g. I noticed exactly the same issue (missing text) with my r600-sb branch because it relies on the number of the parsed inputs from r600g's tgsi translator. It's 1 in this case instead of 2, so second input register is considered undefined and optimized away. I suspect that some other drivers may also handle this declaration incorrectly and this may explain the issue. Vadim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On 03/22/2013 05:50 PM, Marek Olšák wrote: Hi everyone, one image is better than a thousand words: http://people.freedesktop.org/~mareko/gallium-hud.png So there you have it. This gallium module can draw transparent graphs and text on top of what apps are rendering. By default, it can show framerate, cpu load (each CPU or the average of all of them), and the results of PRIMITIVES_GENERATED and OCCLUSION_COUNTER queries (the latter is printed as pixels rendered). Furthermore, there is a new interface for gallium allowing drivers to expose driver-specific queries in a way similar to GL_AMD_performance_monitor. It uses the existing pipe_query interface. Drivers can use this to expose performance counters or other internal information. BTW, I guess I should mention that I ripped the font off from freeglut. The HUD is controlled by the GALLIUM_HUD environment variable, where you can list names of data sources. Set GALLIUM_HUD=help for more info, it also prints all available names (including the driver-specific queries). This is what I used for the image above: GALLIUM_HUD=cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered So basically I'd like to be able to display as much useful info in the HUD as possible. We should definitely add some ioctls for querying useful stats from the kernel DRM/TTM and be able to see in real time what happens in Mesa and the kernel. It's pretty easy - just expose a new query through the gallium interface and the HUD will automatically pick it up. (for moderators: the second patch might get stuck in the moderation queue) This looks really great, Marek! Could you update the gallium docs with your interface additions? Could you also create a Mesa/docs/ page which describes how this works and how to use it? I can't wait to try this with llvmpipe and the svga driver. I'll try to review your patches ASAP... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On 03/25/2013 08:45 AM, Brian Paul wrote: On 03/22/2013 05:50 PM, Marek Olšák wrote: Hi everyone, one image is better than a thousand words: http://people.freedesktop.org/~mareko/gallium-hud.png So there you have it. This gallium module can draw transparent graphs and text on top of what apps are rendering. By default, it can show framerate, cpu load (each CPU or the average of all of them), and the results of PRIMITIVES_GENERATED and OCCLUSION_COUNTER queries (the latter is printed as pixels rendered). Furthermore, there is a new interface for gallium allowing drivers to expose driver-specific queries in a way similar to GL_AMD_performance_monitor. It uses the existing pipe_query interface. Drivers can use this to expose performance counters or other internal information. BTW, I guess I should mention that I ripped the font off from freeglut. The HUD is controlled by the GALLIUM_HUD environment variable, where you can list names of data sources. Set GALLIUM_HUD=help for more info, it also prints all available names (including the driver-specific queries). This is what I used for the image above: GALLIUM_HUD=cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered So basically I'd like to be able to display as much useful info in the HUD as possible. We should definitely add some ioctls for querying useful stats from the kernel DRM/TTM and be able to see in real time what happens in Mesa and the kernel. It's pretty easy - just expose a new query through the gallium interface and the HUD will automatically pick it up. (for moderators: the second patch might get stuck in the moderation queue) This looks really great, Marek! Could you update the gallium docs with your interface additions? Could you also create a Mesa/docs/ page which describes how this works and how to use it? I can't wait to try this with llvmpipe and the svga driver. I'll try to review your patches ASAP... OK, I did a quick pass through the series and it looks good to me. Reviewed-by: Brian Paul bri...@vmware.com After you check this in I'll hook the HUD into the st/xlib code for llvmpipe... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
I feel rather awkward asking, but: why implement this inside of
Gallium, instead of as a standalone {egl,glX}SwapBuffers interceptor
obtaining counter values via GL extensions, such as
ARB_occlusion_query or AMD_performance_monitor? That way Intel (and
Nouveau?) people could also benefit from it.
Best regards,
Alexander
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
- Original Message - Hi everyone, one image is better than a thousand words: http://people.freedesktop.org/~mareko/gallium-hud.png So there you have it. This gallium module can draw transparent graphs and text on top of what apps are rendering. By default, it can show framerate, cpu load (each CPU or the average of all of them), and the results of PRIMITIVES_GENERATED and OCCLUSION_COUNTER queries (the latter is printed as pixels rendered). Furthermore, there is a new interface for gallium allowing drivers to expose driver-specific queries in a way similar to GL_AMD_performance_monitor. It uses the existing pipe_query interface. Drivers can use this to expose performance counters or other internal information. BTW, I guess I should mention that I ripped the font off from freeglut. The HUD is controlled by the GALLIUM_HUD environment variable, where you can list names of data sources. Set GALLIUM_HUD=help for more info, it also prints all available names (including the driver-specific queries). This is what I used for the image above: GALLIUM_HUD=cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered So basically I'd like to be able to display as much useful info in the HUD as possible. We should definitely add some ioctls for querying useful stats from the kernel DRM/TTM and be able to see in real time what happens in Mesa and the kernel. It's pretty easy - just expose a new query through the gallium interface and the HUD will automatically pick it up. Hi Marek, Sounds good in principle (and looks great in the screenshot!) I've skimmed through http://cgit.freedesktop.org/~mareko/mesa/log/?h=hud and one thing I noticed is that there isn't a consistent prefix in the new hud module symbols/defines/source files (hud_ is used in most cases, but not all). Please standardize that to prevent symbol collisions. The gallium interface changes look alright. We might eventually want to standardize some of these performance counters, but it looks perfectly adequate for now. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
That's a very good question. There are a couple of reasons for this.
1) Writing any kind of meta operation and custom rendering code on top
of GL is a horrible idea and very prone to errors. If you don't
restore all states after you're done, you may break the application.
If the application sets a state you didn't take into account, it may
break the HUD rendering. And there is a lot of functionality in GL
that must be taken into account, while it's pretty simple with
Gallium, which has tools for saving and restoring states.
2) I would have to add code paths for GL2, GL3 core, GLES1, and GLES2.
I don't really want to worry about all those APIs or any future API.
It might also be interesting to use the HUD with non-OpenGL state
trackers, like st/xorg and st/xa.
3) Gallium has lower overhead than GL and the HUD should have as
little impact on framerate as possible.
I'm pretty sure everybody will benefit from this except Intel. I
wholeheartedly wish the situation were different, but there is nothing
I can do about that.
Marek
On Mon, Mar 25, 2013 at 5:47 PM, Alexander Monakov amona...@gmail.com wrote:
I feel rather awkward asking, but: why implement this inside of
Gallium, instead of as a standalone {egl,glX}SwapBuffers interceptor
obtaining counter values via GL extensions, such as
ARB_occlusion_query or AMD_performance_monitor? That way Intel (and
Nouveau?) people could also benefit from it.
Best regards,
Alexander
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On Mon, Mar 25, 2013 at 6:14 PM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - Hi everyone, one image is better than a thousand words: http://people.freedesktop.org/~mareko/gallium-hud.png So there you have it. This gallium module can draw transparent graphs and text on top of what apps are rendering. By default, it can show framerate, cpu load (each CPU or the average of all of them), and the results of PRIMITIVES_GENERATED and OCCLUSION_COUNTER queries (the latter is printed as pixels rendered). Furthermore, there is a new interface for gallium allowing drivers to expose driver-specific queries in a way similar to GL_AMD_performance_monitor. It uses the existing pipe_query interface. Drivers can use this to expose performance counters or other internal information. BTW, I guess I should mention that I ripped the font off from freeglut. The HUD is controlled by the GALLIUM_HUD environment variable, where you can list names of data sources. Set GALLIUM_HUD=help for more info, it also prints all available names (including the driver-specific queries). This is what I used for the image above: GALLIUM_HUD=cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered So basically I'd like to be able to display as much useful info in the HUD as possible. We should definitely add some ioctls for querying useful stats from the kernel DRM/TTM and be able to see in real time what happens in Mesa and the kernel. It's pretty easy - just expose a new query through the gallium interface and the HUD will automatically pick it up. Hi Marek, Sounds good in principle (and looks great in the screenshot!) I've skimmed through http://cgit.freedesktop.org/~mareko/mesa/log/?h=hud and one thing I noticed is that there isn't a consistent prefix in the new hud module symbols/defines/source files (hud_ is used in most cases, but not all). Please standardize that to prevent symbol collisions. Alright, though too many underscores in a function name looks scary. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote: Hi everyone, one image is better than a thousand words: ... Hi, I tried your patches and hit a few problems. As first, they do not apply cleanly on master as they are expecting another your patch cso: add constant buffer save/restore feature for postprocessing to be present. But I guess you are aware of that. Second problem is that when I build mesa with HUD on my 32bit virtual machine, HUD works (with 32bit app of course). When I build it on 64bit (both are same uptodate OS openSUSE 12.3), HUD is not working (with 64bit app). I managed to track it down to failed IMM instruction parsing during HUD_create function. It appears that translate_ctx structure in tgsi_text_translate (file src/gallium/auxiliary/tgsi/tgsi_text.c) is not initialized to zeros under my 64bit system, instead ctx.num_immediates is equal to 1 and hence trigger Immediates must be sorted error. Following fixes HUD for me (note that I really don't know if I am not broking something here in regards to mesa): diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 6b97bee..247ec75 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1577,6 +1577,7 @@ tgsi_text_translate( ctx.tokens = tokens; ctx.tokens_cur = tokens; ctx.tokens_end = tokens + num_tokens; + ctx.num_immediates = 0; if (!translate( ctx )) return FALSE; The third issue is that on both 32bit and 64bit build fonts are not displayed in HUD. I see graphs and transparent background rectangles for text but no text is visible. This one I did not yet solve. One last thought, is it intentional when wrong query is entered that hud graph is displayed but empty? Maybe some text like wrong query XXX would be a good hint. I know it is printed on stdout but looking for warnings in chatty apps like openarena is little tricky. Thanks for your work, OH ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On 03/25/2013 03:38 PM, Ondrej Holecek wrote: On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote: Hi everyone, one image is better than a thousand words: ... Hi, I tried your patches and hit a few problems. As first, they do not apply cleanly on master as they are expecting another your patch cso: add constant buffer save/restore feature for postprocessing to be present. But I guess you are aware of that. Second problem is that when I build mesa with HUD on my 32bit virtual machine, HUD works (with 32bit app of course). When I build it on 64bit (both are same uptodate OS openSUSE 12.3), HUD is not working (with 64bit app). I managed to track it down to failed IMM instruction parsing during HUD_create function. It appears that translate_ctx structure in tgsi_text_translate (file src/gallium/auxiliary/tgsi/tgsi_text.c) is not initialized to zeros under my 64bit system, instead ctx.num_immediates is equal to 1 and hence trigger Immediates must be sorted error. Following fixes HUD for me (note that I really don't know if I am not broking something here in regards to mesa): diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 6b97bee..247ec75 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1577,6 +1577,7 @@ tgsi_text_translate( ctx.tokens = tokens; ctx.tokens_cur = tokens; ctx.tokens_end = tokens + num_tokens; + ctx.num_immediates = 0; if (!translate(ctx )) return FALSE; We should init the whole object to zeros to be safe. I'll post a patch for that. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com wrote: On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote: Hi everyone, one image is better than a thousand words: ... Hi, I tried your patches and hit a few problems. As first, they do not apply cleanly on master as they are expecting another your patch cso: add constant buffer save/restore feature for postprocessing to be present. But I guess you are aware of that. Yes, I sent the patch to mesa-dev earlier. Second problem is that when I build mesa with HUD on my 32bit virtual machine, HUD works (with 32bit app of course). When I build it on 64bit (both are same uptodate OS openSUSE 12.3), HUD is not working (with 64bit app). I managed to track it down to failed IMM instruction parsing during HUD_create function. It appears that translate_ctx structure in tgsi_text_translate (file src/gallium/auxiliary/tgsi/tgsi_text.c) is not initialized to zeros under my 64bit system, instead ctx.num_immediates is equal to 1 and hence trigger Immediates must be sorted error. Following fixes HUD for me (note that I really don't know if I am not broking something here in regards to mesa): diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 6b97bee..247ec75 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1577,6 +1577,7 @@ tgsi_text_translate( ctx.tokens = tokens; ctx.tokens_cur = tokens; ctx.tokens_end = tokens + num_tokens; + ctx.num_immediates = 0; if (!translate( ctx )) return FALSE; I've sent a fix for this a couple of days ago: http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg36038.html The third issue is that on both 32bit and 64bit build fonts are not displayed in HUD. I see graphs and transparent background rectangles for text but no text is visible. This one I did not yet solve. Your driver must support the I8_UNORM texture format. One last thought, is it intentional when wrong query is entered that hud graph is displayed but empty? Maybe some text like wrong query XXX would be a good hint. I know it is printed on stdout but looking for warnings in chatty apps like openarena is little tricky. Yes, it's intentional. I guess I can at least make it not draw an empty pane. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
Pushed, except for creating a page in mesa/docs. I'll do that some time later. Marek On Mon, Mar 25, 2013 at 3:45 PM, Brian Paul bri...@vmware.com wrote: On 03/22/2013 05:50 PM, Marek Olšák wrote: Hi everyone, one image is better than a thousand words: http://people.freedesktop.org/~mareko/gallium-hud.png So there you have it. This gallium module can draw transparent graphs and text on top of what apps are rendering. By default, it can show framerate, cpu load (each CPU or the average of all of them), and the results of PRIMITIVES_GENERATED and OCCLUSION_COUNTER queries (the latter is printed as pixels rendered). Furthermore, there is a new interface for gallium allowing drivers to expose driver-specific queries in a way similar to GL_AMD_performance_monitor. It uses the existing pipe_query interface. Drivers can use this to expose performance counters or other internal information. BTW, I guess I should mention that I ripped the font off from freeglut. The HUD is controlled by the GALLIUM_HUD environment variable, where you can list names of data sources. Set GALLIUM_HUD=help for more info, it also prints all available names (including the driver-specific queries). This is what I used for the image above: GALLIUM_HUD=cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered So basically I'd like to be able to display as much useful info in the HUD as possible. We should definitely add some ioctls for querying useful stats from the kernel DRM/TTM and be able to see in real time what happens in Mesa and the kernel. It's pretty easy - just expose a new query through the gallium interface and the HUD will automatically pick it up. (for moderators: the second patch might get stuck in the moderation queue) This looks really great, Marek! Could you update the gallium docs with your interface additions? Could you also create a Mesa/docs/ page which describes how this works and how to use it? I can't wait to try this with llvmpipe and the svga driver. I'll try to review your patches ASAP... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/5] Head-up display for Gallium DRI2 drivers
Hi everyone, one image is better than a thousand words: http://people.freedesktop.org/~mareko/gallium-hud.png So there you have it. This gallium module can draw transparent graphs and text on top of what apps are rendering. By default, it can show framerate, cpu load (each CPU or the average of all of them), and the results of PRIMITIVES_GENERATED and OCCLUSION_COUNTER queries (the latter is printed as pixels rendered). Furthermore, there is a new interface for gallium allowing drivers to expose driver-specific queries in a way similar to GL_AMD_performance_monitor. It uses the existing pipe_query interface. Drivers can use this to expose performance counters or other internal information. BTW, I guess I should mention that I ripped the font off from freeglut. The HUD is controlled by the GALLIUM_HUD environment variable, where you can list names of data sources. Set GALLIUM_HUD=help for more info, it also prints all available names (including the driver-specific queries). This is what I used for the image above: GALLIUM_HUD=cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered So basically I'd like to be able to display as much useful info in the HUD as possible. We should definitely add some ioctls for querying useful stats from the kernel DRM/TTM and be able to see in real time what happens in Mesa and the kernel. It's pretty easy - just expose a new query through the gallium interface and the HUD will automatically pick it up. (for moderators: the second patch might get stuck in the moderation queue) Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
