[Bug 21708] New: d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

Summary: d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when
                    driver doesn't support ARB_depth_texture
           Product: Wine
           Version: 1.1.38
          Platform: x86
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: directx-d3d
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

ARB_depth_texture (and ARB_shadow) was moved to opengl core only in 1.4. radeon
r200 cards don't have hw support or depth textures so mesa r200 driver only
supports 1.3.

If I run 3DMark2001 in wine with r200 I get INVALID_ENUM errors for call to
glTexParameter(GL_DEPTH_TEXTURE_MODE_ARB). The problematic demo is the high
detail lobby.

If directx 8 did require something similar to ARB_shadow and ARB_depth_texture
then it would be interesting to know if ati did support them in windows driver.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

Roderick Colenbrander  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Roderick Colenbrander   2010-03-21 17:05:01 ---
These extensions were not offered on these cards in GL mode (see
http://ati.amd.com/developer/atiopengl.pdf). I don't know much about this area
of wined3d, so can't help. It might be that they used software emulation or
used some GPU features which are not exposed through OpenGL.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #2 from Roderick Colenbrander   2010-04-28 06:33:23 ---
The only place where we are making such call is in surface.c:
glTexParameteri(bind_target, GL_DEPTH_TEXTURE_MODE_ARB, GL_LUMINANCE);

Is this the offending call in your case? If it is then I find it a bit
surprising since that path is only used when FBOs are around. Do your drivers
offer GL_EXT_framebuffer_object / GL_ARB_framebuffer_object? (typically this
extension is only around on OpenGL 2.0 capable cards) The code won't be entered
if you set the OffscreenRenderingMethod to backbuffer.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #3 from Roderick Colenbrander   2010-04-28 06:34:44 ---
I forgot to ask does it result in rendering errors?

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #4 from Pauli Nieminen   2010-05-02 22:04:41 ---
Replying with email doesn't work :/
> --- Comment #2 from Roderick Colenbrander   2010-04-28 06:33:23 ---
> The only place where we are making such call is in surface.c:
> glTexParameteri(bind_target, GL_DEPTH_TEXTURE_MODE_ARB, GL_LUMINANCE);
>
> Is this the offending call in your case? If it is then I find it a bit
> surprising since that path is only used when FBOs are around. Do your drivers
> offer GL_EXT_framebuffer_object / GL_ARB_framebuffer_object? (typically this
> extension is only around on OpenGL 2.0 capable cards) The code won't be entered
> if you set the OffscreenRenderingMethod to backbuffer.

Yes. Open source radeon supports FBOs even with older hw (r100 and
r200 that are only GL1.3/1.5 hardware). But FBO support is missing
depth textures because of no texture format for depth buffer in the
old hw.
> I forgot to ask does it result in rendering errors?

And I see that error when testing 3DMark2001SE lobby demo. It used to
render correctly but now it fails to render characters.
I don't know if incorrect rendering is caused by the error message.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

Stefan Dösinger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #5 from Stefan Dösinger   2010-05-10 11:47:48 ---
I haven't done any serious work on my ATI radeon 9000 for a while. It sounds as
if depth testing is working fine with a GL_DEPTH_COMPONENT texture attached to
a FBO, but since GL_ARB_depth_texture isn't supported it can't be used for
sampling from the texture.

This would be a reasonable thing in terms of hardware support. FBOs without
depth buffers are useless, but it's just fine to use the texture for the depth
test only, and not for shadows. However, I'm not quite sure how legal this is
from a GL API perspective, because technically DEPTH_COMPONENT cannot be used
for creating a texture without depth_texture support.

I can see 3 possibilities:
1) We can use renderbuffers(not texturable GL surfaces)
2) We make this a driver quirk and just test for the depth texture mode set
error
3) The Mesa devs push out a new extension to clarify the situation

I think (1) is the best thing to do(if it works), but it's a lot of
infrastructure work. We need it for multisampling though.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #6 from Austin English  2012-03-19 14:53:07 CDT ---
This is your friendly reminder that there has been no bug activity for 650
days. Is this still an issue in current (1.4 or newer) wine?

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

Stefan Dösinger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #7 from Stefan Dösinger  2012-03-20 04:53:53 CDT ---
I don't know of anything that would have fixed this bug, but I'd prefer to hear
from someone who is still using an r200 GPU.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

Rafał Mużyło  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #8 from Rafał Mużyło  2012-11-17 19:34:02 CST ---
(In reply to comment #7)
> I don't know of anything that would have fixed this bug, but I'd prefer to hear
> from someone who is still using an r200 GPU.

I'm not sure about this bug in itself, but I've got an r200 and in some of the
cases I can see significant difference between fbo (with black texture covering
the window) and backbuffer (looking mostly OK).

The errors are about 
fixme:d3d_surface:surface_allocate_surface No GL internal format for format
WINED3DFMT_D16_UNORM.
This seems to relate somewhat to ARB_DEPTH_TEXTURE (according to
dlls/wined3d/utils.c), so if there are some simple tests I could run, I'd try
to give some useful feedback.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #9 from Stefan Dösinger  2012-11-18 05:10:37 CST ---
Created attachment 42534
  --> http://bugs.winehq.org/attachment.cgi?id=42534
wined3d: Remove ARB_depth_texture requirement for  D3DFMT_D16_UNORM (HACK)

Out of curiosity, does this hack make it any better? It's by no means a correct
fix, but it might just be enough to get those games going.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #10 from Stefan Dösinger  2012-11-18 06:48:57 CST ---
I checked the capabilities the d3d driver of my r250 GPU advertises on Windows.
It supports D16, D24S8, D24X8 and D16_LOCKABLE as depth stencil surfaces, but
not as textures. That matches the capabilities of depth renderbuffers.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

Stefan Dösinger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|[e-mail]      |

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #11 from Rafał Mużyło  2012-11-18 08:58:14 CST ---
(In reply to comment #9)
> Created attachment 42534 [details]
> wined3d: Remove ARB_depth_texture requirement for  D3DFMT_D16_UNORM (HACK)
>
> Out of curiosity, does this hack make it any better? It's by no means a correct
> fix, but it might just be enough to get those games going.

Well, for the display, it makes no difference.

For the console output, it does.

err:d3d_surface:surface_allocate_surface >>>>>>>>>>>>>>>>> GL_INVALID_VALUE
(0x501) from glTexImage2D @ surface.c / 2748
fixme:d3d:context_check_fbo_status FBO status
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6)
fixme:d3d:context_check_fbo_status      Location SFLAG_INTEXTURE (0x40000).
fixme:d3d:context_check_fbo_status      Color attachment 0: (0x194730)
WINED3DFMT_B8G8R8X8_UNORM 800x600 0 samples.
fixme:d3d:context_check_fbo_status      Depth attachment: (0x194888)
WINED3DFMT_D16_UNORM 800x600 0 samples.
err:d3d:device_clear_render_targets >>>>>>>>>>>>>>>>>
GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glClear @device.c / 777
fixme:d3d:context_check_fbo_status FBO status
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6)
fixme:d3d:context_check_fbo_status      Location SFLAG_INTEXTURE (0x40000).
fixme:d3d:context_check_fbo_status      Color attachment 0: (0x194730)
WINED3DFMT_B8G8R8X8_UNORM 800x600 0 samples.
fixme:d3d:context_check_fbo_status      Depth attachment: (0x194888)
WINED3DFMT_D16_UNORM 800x600 0 samples.

err:d3d:device_clear_render_targets >>>>>>>>>>>>>>>>>
GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glClear @ device.c / 815
fixme:d3d:context_check_fbo_status FBO status
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6)
fixme:d3d:context_check_fbo_status      Location SFLAG_INTEXTURE (0x40000).
fixme:d3d:context_check_fbo_status      Color attachment 0: (0x194730)
WINED3DFMT_B8G8R8X8_UNORM 800x600 0 samples.
fixme:d3d:context_check_fbo_status      Depth attachment: (0x194888)
WINED3DFMT_D16_UNORM 800x600 0 samples.
err:d3d_draw:drawStridedSlow >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION
(0x506) from glEnd and previous calls @ drawprim.c / 310
fixme:d3d:context_check_fbo_status FBO status
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6)
fixme:d3d:context_check_fbo_status      Location SFLAG_INTEXTURE (0x40000).
fixme:d3d:context_check_fbo_status      Color attachment 0: (0x194730)
WINED3DFMT_B8G8R8X8_UNORM 800x600 0 samples.
fixme:d3d:context_check_fbo_status      Depth attachment: (0x194888)
WINED3DFMT_D16_UNORM 800x600 0 samples.

This 4 types now flood the console.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #12 from Stefan Dösinger  2012-11-18 10:15:11 CST ---
Created attachment 42536
  --> http://bugs.winehq.org/attachment.cgi?id=42536
wined3d: Always use a renderbuffer for the depth stencil  attachment(HACK)

The GL errors you get make sense. They confirm that the driver indeed doesn't
support depth textures, and not just forgot to advertise the extension.

Can you try this patch on top of the previous one? It forces the use of a
render buffer rather than a texture for the depth stencil surface. I haven't
tested it, so it might be totally broken.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #13 from Rafał Mużyło  2012-11-18 11:22:00 CST ---
Now the window is still black, but instead of previous errors, there's only
this one printed repeatedly:
fixme:d3d_surface:surface_load_ds_location Not supported with fixed up depth
stencil.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #14 from Rafał Mużyło  2012-11-18 11:24:24 CST ---
...and it might be of interest, that there's one constant fixme present
regardless of the changes, appearing once before others:
fixme:d3d:state_zenable Z buffer disabled, but ARB_depth_clamp isn't supported.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #15 from Stefan Dösinger  2012-11-18 11:41:39 CST ---
Which game are you testing by the way?

(In reply to comment #14)
> fixme:d3d:state_zenable Z buffer disabled, but ARB_depth_clamp isn't supported.

This FIXME is harmless in most games. The interesting question is why the Z
buffer is disabled. Either the game explicitly disables it(ok), or there is no
depth buffer(maybe ok, maybe not). Can you check if there's a line "No Z buffer
- disabling depth test" in a +d3d log?

(In reply to comment #14)
> Now the window is still black, but instead of previous errors, there's only
> this one printed repeatedly:
> fixme:d3d_surface:surface_load_ds_location Not supported with fixed up depth
> stencil.

This fixme is a side effect of the hack. It may cause rendering problems, but I
suspect something else is broken.

Please try(on top of my two hacks) to set the following registry key:
HKEY_CURRENT_USER/Software/Wine/Direct3D/AlwaysOffscreen = "disabled"

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #16 from Rafał Mużyło  2012-11-18 12:15:32 CST ---
(In reply to comment #15)
> (In reply to comment #14)
> > fixme:d3d:state_zenable Z buffer disabled, but ARB_depth_clamp isn't supported.
>
> This FIXME is harmless in most games. The interesting question is why the Z
> buffer is disabled. Either the game explicitly disables it(ok), or there is no
> depth buffer(maybe ok, maybe not). Can you check if there's a line "No Z buffer
> - disabling depth test" in a +d3d log?

No such line in the log.
> (In reply to comment #14)
> > Now the window is still black, but instead of previous errors, there's only
> > this one printed repeatedly:
> > fixme:d3d_surface:surface_load_ds_location Not supported with fixed up depth
> > stencil.
>
> This fixme is a side effect of the hack. It may cause rendering problems, but I
> suspect something else is broken.
>
> Please try(on top of my two hacks) to set the following registry key:
> HKEY_CURRENT_USER/Software/Wine/Direct3D/AlwaysOffscreen = "disabled"

With this regkey, it seems to be displayed correctly.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #17 from Stefan Dösinger  2012-11-18 12:18:26 CST ---
Ok, so at least the swapchain present blit is broken. That should be fixable.

Depending on your game, setting this key is probably enough to get it working.
My patches only matter if the game uses offscreen rendering itself. What
game(s) are you trying to run?

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #18 from Rafał Mużyło  2012-11-18 12:39:59 CST ---
Indeed, after reverting the hacks, the regkey does suffice.
As for the game, it's nothing widely used.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

Stefan Dösinger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #19 from Stefan Dösinger  2012-11-23 03:13:54 CST ---
I had a quick look at the FBO capabilities of the r200 driver. A depth
renderbuffer seems to work as expected(the depth test works ok) and overall
EXT_fbo functionality is there as well. There's no ARB_fbo or EXT_fbo_blit
support though.

The non-fbo-blit swapchain present code is broken. The first problem I
identified is that we don't bind the backbuffer texture when we try to draw the
textured quad onto the window. With that fixed, the d3d sdk samples show the
clear background color rather than black. There is some other problem that
seems to prevent draws from succeeding, and I haven't found this yet.

Making wined3d use renderbuffers instead of textures for the depth stencil will
be harder. I probably won't implement this for this card alone, unless a lot of
people who still use this card or a r100 one show up. There are other
motivations for using rbs, like possible performance improvements. If/when the
time comes to do this work I'll keep the r200 GPU in mind.

Also the performance of the r200 driver is still crap, compared to the
performance it had prior to the introduction of KMS. That applies to Wine and
Linux-native games.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #20 from Stefan Dösinger  2012-12-05 15:50:08 CST ---
Commit 7b95df03c683e52b31d0e6a9e9e81072139c8f14 should improve the situation
with AlwaysOffscreen = enabled somewhat. Depending on your application, you
might run into https://bugs.freedesktop.org/show_bug.cgi?id=57842 . If you
don't hit that bug, things might work with AlwaysOffscreen=enabled and my two
hacks.

However, AlwaysOffscreen=enabled is mostly an academic exercise. On r200, not
rendering to an FBO is faster anyway, unless the application renders to
offscreen surfaces itself.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #21 from Rafał Mużyło  2012-12-10 10:51:44 CST ---
Well, I've just tested things with 1.5.19.

Things are both better and worse.

The display is correct now.

However, it became quite crashy on kernel level.
> From dmesg:

[drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer !
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
a crash follows.

"No GL internal format for format WINED3DFMT_D16_UNORM." is still present
without the regkey, but the crash happens regardless of it.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #22 from Stefan Dösinger  2012-12-10 11:19:39 CST ---
Did you apply the two hacks I attached to this bug report?

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #23 from Rafał Mużyło  2012-12-10 12:03:00 CST ---
(In reply to comment #22)
> Did you apply the two hacks I attached to this bug report?

No - I was under impression that they were no longer needed.

With those two hacks applied, it's not crashy, but a few textures aren't
displayed and the warning from comments 13 and 14 are back.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #24 from Rafał Mużyło  2012-12-21 18:10:39 CST ---
A little note regarding 1.5.20 or rather something I've failed to notice in the
earlier test (this is without using the source hacks):
while the regkey helps in that it doesn't almost instantly crash, it still
crashes under certain conditions with a different warning just before the crash

err:d3d_surface:surface_set_compatible_renderbuffer >>>>>>>>>>>>>>>>>
GL_INVALID_ENUM (0x500) from set_compatible_renderbuffer @
dlls/wined3d/surface.c / 2778

This most likely is yet another hardware limitation of r200, but is it the same
one ?

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #25 from Stefan Dösinger  2012-12-22 05:16:26 CST ---
(In reply to comment #24)
> err:d3d_surface:surface_set_compatible_renderbuffer >>>>>>>>>>>>>>>>>
> GL_INVALID_ENUM (0x500) from set_compatible_renderbuffer @
> dlls/wined3d/surface.c / 2778

I think the application tries to do offscreen rendering itself. That's what the
two hacks are intended to address.

You mentioned "missing textures" with my hacks. Can you attach a screenshot of
the problem, and, if possible, a screenshot of the correct rendering?

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #26 from Rafał Mużyło  2012-12-22 12:36:12 CST ---
Created attachment 42904
  --> http://bugs.winehq.org/attachment.cgi?id=42904
correct display

Here you go: this is the correct display...

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #27 from Rafał Mużyło  2012-12-22 12:38:17 CST ---
Created attachment 42905
  --> http://bugs.winehq.org/attachment.cgi?id=42905
incorrect display

...and this has missing 'background'.

On not quite related note: it seems I've stumbled upon yet another font
regression.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #28 from Stefan Dösinger  2012-12-22 14:39:06 CST ---
Created attachment 42907
  --> http://bugs.winehq.org/attachment.cgi?id=42907
wined3d: hack: disable culling

Can you try this hack on top of the other two hacks? It is a workaround for
https://bugs.freedesktop.org/show_bug.cgi?id=57842 .

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #29 from Rafał Mużyło  2012-12-22 16:46:19 CST ---
Created attachment 42909
  --> http://bugs.winehq.org/attachment.cgi?id=42909
a broken cursor

Indeed, this additional hack helped. So, you're saying that this part is
basically a driver bug ?

Though independent of this new hack, there's a different problem:
look at this screenshot, notice cursor - one in many instances.
For some reason, those two previous hacks have occasionally, but reproducibly
this effect on the cursor.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #30 from Stefan Dösinger  2012-12-22 17:35:04 CST ---
The cursor symptom looks like the background is not redawn correctly. This
could be a side effect of the hacks, or because the hacks are incomplete
solutions.

The missing background fixed by attachment 42907 is a driver bug. The issues
addressed by the other patches are legitimate driver limitations that aren't
handled correctly by Wine.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #31 from Rafał Mużyło  2012-12-22 18:32:45 CST ---
Could the fact that r200 has only GL_EXT_framebuffer_object, not
GL_ARB_framebuffer_object, play a role in the driver bug ?

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #32 from Stefan Dösinger  2012-12-23 04:13:46 CST ---
No, that's not the reason for the driver bug. The GPU chip behaves somewhat
strange. The driver code looks ok, but for some reason the GPU decides to
discard all geometry if the viewport dimensions are not inverted. I don't have
the GPU docs to see what the intended behavior is.

Maybe the driver has to be changed to always invert the viewport, and invert
all geometry when rendering offscreen to cancel out the y coordinate flip.
That'd be a pain with vertex shaders though.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #33 from Stefan Dösinger  2012-12-23 04:15:45 CST ---
Fwiw, the lack of ARB_fbo is the reason for the
"fixme:d3d_surface:surface_load_ds_location Not supported with fixed up depth
stencil." line. But due to the hacky nature of my hacks even having ARB_fbo
wouldn't help. Proper handling of depth renderbuffers would be needed here.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #34 from Rafał Mużyło  2013-02-08 17:35:35 CST ---
I'm a bit late again.
There has been regression in wine 1.5.23, that's sort of, but not quite is
related to this bug, in the way, that most likely it can happen only on cards
as old as r200.

I've bisected it to 3f21757702239f1c254cdc860d71e76e9929d409.

The problem happens to be 
if (wined3d_settings.vs_mode == VS_NONE && wined3d_settings.ps_mode == PS_NONE)
  return &none_shader_backend;

It seems that on an r200 only one of those conditions is false, leading to
select_shader_backend returning arb_program_shader_backend instead of
none_shader_backend. That in turn leads to completely corrupted display.

Alternatively,
if (gl_info->supported[ARB_VERTEX_PROGRAM] &&
gl_info->supported[ARB_FRAGMENT_PROGRAM])
  &arb_program_shader_backend;

could be the problem/solution, as toggling the condition && <-> || in *either*
seems to fix the problem.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #35 from Stefan Dösinger  2013-02-08 17:53:29 CST ---
Does http://source.winehq.org/patches/data/94198 help?

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #36 from Rafał Mużyło  2013-02-08 19:40:45 CST ---
(In reply to comment #35)
> Does http://source.winehq.org/patches/data/94198 help?

Seems it does, thanks.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #37 from Rafał Mużyło  2013-05-24 23:04:52 CDT ---
Well, once again I haven't been checking for a few wine versions and -
predictably - got bitten by a corner case again.
At 1.5.28 things worked as good/bad as they were, at 1.5.31 all I get from the
testcase is:
err:d3d:wined3d_adapter_init_gl_caps Received a NULL GL_RENDERER.
err:d3d:wined3d_adapter_init Failed to initialize GL caps for adapter 0x138c48.

followed by a crash.
...
yay...

Is this progress or regression ?
On one hand, it only worked somewhat sanely due to hacks, on the other, it
*did* work.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #38 from Rafał Mużyło  2013-05-26 13:35:17 CDT ---
OK, bisected it - it dates back to 1.5.29.

Unfortunately, it's not really clear what goes wrong.

Bisect stops on 
5115f55eebe5cb91f13896862275e236a4954744 (wined3d: Use WGL_ARB_create_context
when available.)

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

Rafał Mużyło  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #39 from Rafał Mużyło  2013-05-26 14:34:35 CDT ---
OK, I might have found a fix, but it looks a bit odd.
It simply delays  wined3d_create_fake_gl_context_attribs call in
wined3d_adapter_init a few lines.
I'm not sure it's a corect solution, so I'm not sending the patch yet.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #40 from Rafał Mużyło  2013-05-26 14:51:48 CDT ---
Created attachment 44564
  --> http://bugs.winehq.org/attachment.cgi?id=44564
fix for the crash

This is the change I was talking about.
I can't really tell, if that's what it was supposed to be in the first place or
is it simply a hack.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #41 from Henri Verbeet  2013-05-26 15:04:46 CDT ---
That patch doesn't really make sense, though it does suggest something goes
wrong with the wglCreateContextAttribsARB() call. From what you posted it seems
it doesn't create a context / creates a broken context, but doesn't return an
error either.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #42 from Rafał Mużyło  2013-05-26 21:51:50 CDT ---
Well, the patch works, so it looks as before it, wine can create a situation
where device->contexts[0]->glCtx exists, but device->context_count is zero.

Well, at least that's my guess, that the patch was based upon, before it tested
positively.

Perhaps one of the functions isn't initializing all of the fields ?

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #43 from Rafał Mużyło  2013-06-08 11:46:47 CDT ---
One way or the other, if any fixes for this were merged into 1.6_rc1, they
aren't working - the hack still seems to be.

On a semi-related note: a fix for 6ab04040e52465e77558a067309e8a54bdc0f32c
regression would be nice too (as my hack/partial revert got rejected awhile
ago).

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #44 from Rafał Mużyło  2013-06-30 23:26:15 CDT ---
The problem noted in comment 37 is still present in 1.6_rc4.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

Rafał Mużyło  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #44564|0                           |1
        is obsolete|                            |

--- Comment #45 from Rafał Mużyło  2013-07-02 20:01:54 CDT ---
Created attachment 45080
  --> http://bugs.winehq.org/attachment.cgi?id=45080
updated hack

I've tried to figure out where exactly things fail, but the only part I
understood was that without the hack it behaves as if glGetString was called
outside active context.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #46 from Rafał Mużyło  2013-08-02 16:06:05 CDT ---
As of 1.7.0, there's nothing new to report - whatever was broken with
wined3d_adapter_init, still is, the hack still works.

No new ideas from me at this time.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #47 from Rafał Mużyło  2013-08-31 18:02:28 CDT ---
So, after being informed about bug 34238, I've tried the testcase.

The results:
./main_linux 
1: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
Inc." version="1.3 Mesa 9.2.0"
2: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
Inc." version="1.3 Mesa 9.1.5"
3: renderer="(null)" vendor="(null)" version="(null)"

(different version entry comes likely from the fact that I've updated mesa
today)

./main.exe
1: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
Inc." version="1.3 Mesa 9.2.0"
2: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
Inc." version="1.3 Mesa 9.1.5"
3: renderer="(null)" vendor="(null)" version="(null)"

LIBGL_ALWAYS_SOFTWARE=1 ./main_linux 
1: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa
9.2.0"
2: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
Inc." version="1.3 Mesa 9.1.5"
3: renderer="(null)" vendor="(null)" version="(null)"

LIBGL_ALWAYS_SOFTWARE=1 ./main.exe
err:winediag:X11DRV_WineGL_InitOpenglInfo The Mesa OpenGL driver is using
software rendering, most likely your 32-bit OpenGL drivers haven't been
installed correctly (using GL renderer "Software Rasterizer", version "2.1 Mesa
9.2.0").
1: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa
9.2.0"
2: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa
9.2.0"
3: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa
9.2.0"

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #48 from Rico  2013-09-01 08:22:36 CDT ---
Created attachment 45801
  --> http://bugs.winehq.org/attachment.cgi?id=45801
glxtest (use direct rendering)

Well, there is a bug in my native linux test case. Requesting an indirect
context with glXCreateContextAttribsARB after a direct in glXCreateContext
seems to always fail later. I'm not sure it should... the ARB_create_context
spec isn't clear in this case (this may be a bug in mesa). Though we may test
this on nvidia and fglrx. I improved the test case a bit. This first point is
not the problem you are seeing.

In your case we may fall into creating an indirect (or in another way
incompatible) context and then fail in mesa. Your log looks a bit question
able...
> 1: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
> Inc." version="1.3 Mesa 9.2.0"
> 2: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
> Inc." version="1.3 Mesa 9.1.5"
> 3: renderer="(null)" vendor="(null)" version="(null)"

Do you have multiple mesa version installed?

The spec says it may create an indirect context, even if you request a direct
one (as wine does). Could you please run the new test (only "./main_linux" and
"wine main.exe")?

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #49 from Henri Verbeet  2013-09-01 08:29:55 CDT ---
(In reply to comment #47)
> So, after being informed about bug 34238, I've tried the testcase.

Thanks, I've added those results to bug 34238. It's probably best to continue
any discussion about that issue there.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

http://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #50 from Rafał Mużyło  2013-09-01 08:42:18 CDT ---
(In reply to comment #48)
> (different version entry comes likely from the fact that I've updated mesa today)

./main_linux
1: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
Inc." version="1.3 Mesa 9.2.0" direct
2: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
Inc." version="1.3 Mesa 9.1.5" indirect
3: renderer="(null)" vendor="(null)" version="(null)" indirect
4: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
Inc." version="1.3 Mesa 9.1.5" indirect
5: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
Inc." version="1.3 Mesa 9.1.5" indirect

./main.exe
1: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
Inc." version="1.3 Mesa 9.2.0"
2: renderer="Mesa DRI R200 (RV280 5964)  TCL DRI2" vendor="Tungsten Graphics,
Inc." version="1.3 Mesa 9.1.5"
3: renderer="(null)" vendor="(null)" version="(null)"

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

https://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #51 from Austin English  ---
This is your friendly reminder that there has been no bug activity for 1 year.
Is this still an issue in current (1.7.31 or newer) wine? If so, please attach
the terminal output in 1.7.31 (see http://wiki.winehq.org/FAQ#get_log).

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

https://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #52 from Rafał Mużyło  ---
(In reply to Austin English from comment #51)
> This is your friendly reminder that there has been no bug activity for 1
> year. Is this still an issue in current (1.7.31 or newer) wine? If so,
> please attach the terminal output in 1.7.31 (see
> http://wiki.winehq.org/FAQ#get_log).

Well, unless the other r200 cards spontaneously mutated...

Seriously, though, things got worse.

With wine 1.7.31.

With 'fbo' either black texture (AlwaysOffscreen = "disabled") or noise
(otherwise) is displayed.

In the console, a flood of:

Mesa: User error: GL_INVALID_FRAMEBUFFER_OPERATION in glBegin(incomplete
framebuffer)
err:d3d:wined3d_debug_callback 0x1e72a0: "GL_INVALID_FRAMEBUFFER_OPERATION in
glBegin(incomplete framebuffer)".
Mesa: User error: GL_INVALID_OPERATION in glEnd
err:d3d:wined3d_debug_callback 0x1e72a0: "GL_INVALID_OPERATION in glEnd".
err:d3d_draw:drawStridedSlow >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION
(0x506) from glEnd and previous calls @ dlls/wined3d/drawprim.c / 339

With 'backbuffer', it initially looks OK, but it dumps a few
"err:d3d:buffer_find_decl no converted attributes found, old conversion map
exists, and no declaration change?", and crashes a bit later. On the other
hand, I haven't been testing it for quite awhile, so the crash might be
unrelated.

...and that's with native, cause with builtin what I get is a few series of
"fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5." followed by

fixme:d3dx:D3DXLoadMeshHierarchyFromXInMemory Loading user data not implemented
fixme:d3dx:D3DXLoadMeshHierarchyFromXInMemory Animation controller creation not
implemented
wine: Call from 0x7ec5f7a1 to unimplemented function
d3dx9_36.dll.D3DXComputeNormals, aborting

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

https://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #53 from Stefan Dösinger  ---
Created attachment 51086
  --> https://bugs.winehq.org/attachment.cgi?id=51086
Set of patches to improve Wine on r200

I've had some spare time yesterday and today and written a few patches that
improve Wine on r200. They fix the use of depth textures, but unfortunately
this part of the patch series is still broken and needs a lot more work. I've
also improved color conversion support in the ATI fragment shader backend and
fixed some bugs there.

The tests run fairly well now on this card. Tests that need a vertex pipeline
replacement still have problems, and tests that need GL_ARB_framebuffer_object
(as opposed to just GL_EXT_framebuffer_object) still fail. Even beyond a vertex
pipeline replacement there are some fog problems that won't be easy to fix,
mostly because the driver always evaluates the fog equation in the vertex
pipeline. There are some defines in the headers that suggest the hardware
should be able to do fragment side fog, but this is not as easy as just setting
a flag and I don't have the hardware documentation.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

https://bugs.winehq.org/show_bug.cgi?id=21708

Sebastian Lackner  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

https://bugs.winehq.org/show_bug.cgi?id=21708

Stefan Dösinger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
      Fixed by SHA1|                            |28af7b407bb926953a73c373eb5
                   |                            |36449d1110e82
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #54 from Stefan Dösinger  ---
This should be fixed by 28af7b407bb926953a73c373eb536449d1110e82. Wined3d now
no longer uses GL depth textures for d3d depth surfaces if GL_ARB_depth_texture
is not supported and uses renderbuffers instead. d3d depth textures are
reported as unsupported to the application in this situation and creating them
generates an error.

There's still a GL error about setting GL_DEPTH_TEXTURE_MODE on sampler
objects. This is a Mesa bug. I have sent a patch a while ago but need to do
more pushing to get it reviewed and committed.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

https://bugs.winehq.org/show_bug.cgi?id=21708

--- Comment #55 from Stefan Dösinger  ---
Also note that r200 seems to have some problems with depth render buffers of
some sizes. Some parts of the buffer are placed incorrectly, causing rendering
artefacts.

[Bug 21708] d3d is trying to use GL_DEPTH_TEXTURE_MODE_ARB when driver doesn't support ARB_depth_texture

https://bugs.winehq.org/show_bug.cgi?id=21708

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #56 from Alexandre Julliard  ---
Closing bugs fixed in 1.7.45.