I forgot to mention that the problem is visible on IvyBridge, I don't have another Intel GPU.

Screenshots of the same frame to compare (the small corruption on the nVidia one might me apitrace or nVidia driver bug, the problem was not visible when just running glretrace).

http://mjesec.ffzg.hr/~vrodic/10003927110-nvidia9800gt.png
http://mjesec.ffzg.hr/~vrodic/10003927110-intelHD4000linux.png

swrast (mesa version 9.0.3) seems to render it just fine, but very slow of course. 

mesa version 9.0.3 from ubuntu 13.04 RC has even more issues with its DRI driver

Correction, swrast in previous comment was actually llvmpipe (9.0.3).

I've tested with current Mesa 9.2 git with llvmpipe and that driver is still rendering fine.  The classic swrast was just too slow.

If it  helps track down the issue - the missing character models appear when rendered above other models.

e.g. http://i.imgur.com/HVq2SNP.jpg

The top of the model renders because it is above the grey creature model. The same thing occurs on stairs and the stones that are just below the character in the screenshot.

I can confirm Bens observation

I made a second trace where I disabled most of other Dota2 world rendering to try to make the frames smaller in number of calls and easier to isolate:

http://mjesec.ffzg.hr/~vrodic/dota/

This trace runs without glitches on nVidia driver as before and on llvmpipe

For the next step in the investigation I'll try to compare piglit runs between llvmpipe and Dota 2 and try to look into tests that fail on Intel/DRI and pass on llvmpipe. I'll try looking at depth buffer, vertex shader and scissor related tests since I got some hints that it might be related to those specific parts of the rendering pipeline.

autoexec.cfg there is a configuration file I ran to autostart dota on a map. It contains commands to temporarily disable rendering of some dota graphics to make the trace file lighter and the problem easier to isolate

You will  have to type 'jointeam good' in dota console to trigger hero selection after the map is loaded if you want to reproduce my test. 

I'm not sure I'll personally have the knowledge to actually fix this, but I'll likely spend some of my free time off work in next few weeks to figure the nature of this bug better.

We also tested on Sandy Bridge, mesa 9.1.1, and exact same bug was visible.

reproduced on intel hd3000 in core i3 2350m

  *-display               
       description: VGA compatible controller
       product: 2nd Generation Core Processor Family Integrated Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 09
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:43 memory:d0000000-d03fffff memory:c0000000-cfffffff ioport:3000(size=64)

Wine has two offscreen rendering modes, configured by OffscreenRenderingMode registry key (documented here: http://wiki.winehq.org/UsefulRegistryKeys)

The default mode is "FBO" mode. In non-default mode, the backbuffer mode, the characters and surrounding foliage trees can be seen, but with artifacts that are probably due to Wine bugs/limitations. However, there are other glitches maybe unrelated to wine.

I've uploaded a set of images with descriptions here http://imgur.com/a/9TgxO, 

I will comment more when I have a chance to test under nVidia to see which artifacts are due to wine and which are due to Intel bugs. 

The captured trace is here: http://mjesec.ffzg.hr/~vrodic/dota/dota2-backbuffer-mode.trace.bz2

But can't be replayed correctly because for some reason glretrace is making the screen flicker so I can see mostly black (no such isuess when actually running with Wine).

Hi,

I confirm this bug too on my hd4000/ corei7, mesa 9.1.2.

The main character seem to be renderer 1 layer under the map decorations.

The other playing characters are rendered fine.

I also confirm the same behaviour in my system with an Intel Ivy Bridge (i7) and a HD4000.

My current configuration is as follows:
wine-1.5.29
mesa 9.2-git (xorg-edgers PPA)
  GL_VERSION:  3.0 Mesa 9.2.0
  GL_VENDOR:   Intel Open Source Technology Center
  GL_RENDERER: Mesa DRI Intel(R) Ivybridge Mobile

Just have tried with today mesa git (16 May 2013), doesn't work too.

I have notice that the character can become full visible, with using a spell/object to be invisible.

I have done tests with the new gallium ilo driver, with HD4000, I have the same display bug.

OpenGL vendor string: LunarG, Inc.
OpenGL renderer string: Gallium 0.4 on Intel(R) Ivybridge Mobile
OpenGL version string: 2.1 Mesa 9.2.0 (git-435aea6)
OpenGL shading language version string: 1.30


So,I'm not sure the problem is in the intel driver.

Does it work with radeon or nouveau gallium?

Other open source drivers without issues are: nouveau (Tested on 9800GT) and the OSS driver for Radeon 6850

Hi,

Today git (30 may 2013), break fully the display with i965 driver. I have now a white screen, with crap everywhere.


So something have change 29may or 30may in git, I see a lot of intel patches.

Git form 28 may was working like before with the display bug.

Note the ilo driver don't have this new problem.

forgot my last message, it's was a temp bug,fixed by

Revert "i965: fix problem with constant out of bounds access (v2)"
http://cgit.freedesktop.org/mesa/mesa/commit/?id=60f9b722ef80c499a94b4e5ab7304dcd739ea569


So, no news for now, the dota display bug is like before.

I've managed to drastically reduce the size of the trace where some problem can be seen:

http://mjesec.ffzg.hr/~vrodic/dota/wine-preloader.137078.trim.trace.bz2

When we dump the state of the last call in trace on nVidia, on GL_COLOR_ATTACHMENT1 we can see some leaf outlines on the bottom left of the screen.

Both Intel/Mesa and gallium/swrast don't show anything here, so it might be a different problem, but it definitely seems to be a problem.

related to comment 17, for some reason wine/dota generates a slightly different trace when run under mesa compared to when run under nvidia GL driver

the minimal trace in comment 17 is from nvidia driver, and this one is with mesa:
http://mjesec.ffzg.hr/~vrodic/dota/wine-preloader.153443.trim-mesa-path.trace.bz2


the mesa one is different that it creates the expected output with both gallium swrast and nvidia binary driver, where the trace from comment 17 only created good output on nvidia binary driver

I did even more trimming and dota 2 configuration tweaking to come up with a even smaller trace file. 

http://mjesec.ffzg.hr/~vrodic/dota/wine-preloader.47082.trim.trace.bz2

When we dump the state of the last call in trace on nVidia or llvm softpipe, on GL_COLOR_ATTACHMENT1 we can see some leaf outlines on the bottom left of the screen (open the full size image in qapitrace).

More details about the last trace: 

- If I disable the fragment shader at call 38758, something can be seen on intel DRI driver on GL_COLOR_ATTACHMENT (obviously incorrect)
- I missed it earlier, but GL_STENCIL_ATTACHMENT also contains the leaf outlines on softpipe driver

Created attachment 80153 [details]
edited trace

One more trace demonstrating that commenting out gl_Fragdata[1,2] writes in the last fragment shader produces "less wrong" results in color attachment 1 [details] [review].  Can somebody familiar with INTEL_DEBUG=wm assembly eyeball the generated code for output target 1 for this and the previous trace?

The debug=wm output looks reasonable to me.  Only funky thing I see at the moment is the gl_FogFragCoord output from the VS not getting dead code eliminated, but that should be fine (looks like output/input mapping works correctly when testing that standalone).

Unfortunately, replay on softpipe is crapping out for me (incomplete framebuffers).

Hi, I would like to help, 

can somebody tell me how to do traces and debug it? (Sorry I'm noob).

Also I notice that ilo and i965g have the same display bug, do they share something in common ?

I've just sent a (fairly dodgy) patch to the mesa list which fixes this.

Confirmed fixed. Thanks Chris!

Works fine here too ! Thanks Chris ! Thanks Vedran !

Fix has been committed by Chris Forbes to mesa master. 

The text below is for people subscribed to this bug that are not necessarily developers.

It should shortly be available in your respective distribution daily builds if your distribution provides them. Ubuntu has something similar in form of Xorg edgers ppa, so the updated build should be possible. 

Using your own build in the meantime should be possible by compiling a 32bit version of mesa master and setting LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH env variables to your src/mesa/lib directory before running wine Dota 2.

My Ivy Bridge mobile i5 runs Dota just fine with some effects disabled on a full screeen 1920x1080 monitor.

Hi guys,

I have just updated my Mesa drivers through edgers ppa for Ubuntu and it works like a charm!

My Ivy Bridge i7 in 1920x1080 renders Dota2 with a reasonable performance.

I want to thank everybody for this patch.

Also, the native Linux client is now available on Steam (admittedly in beta testing), so you may want to try that.

Some interesting bugs on Mesa/Intel, and afaik on all Mesa using
machines clients: https://github.com/ValveSoftware/Dota-2/issues/38

On Thu, Jul 11, 2013 at 8:25 PM,  <bugzilla-daemon@freedesktop.org> wrote:
> Comment # 29 on bug 62647 from Kenneth Graunke
>
> Also, the native Linux client is now available on Steam (admittedly in beta
> testing), so you may want to try that.
>
> ________________________________
> You are receiving this mail because:
>
> You are on the CC list for the bug.
> You reported the bug.

Can we have a new bug for issues in the native client?

*** Bug 67877 has been marked as a duplicate of this bug. ***

(In reply to comment #31)
> Can we have a new bug for issues in the native client?

This is now confirmed fixed with mesa-9.1.6.