https://bugs.freedesktop.org/show_bug.cgi?id=57875
Marek Ol??k changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=57875
Marek Olšák changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #32 from Marek Ol??k ---
There would be no advantage for r300g.
The problem with r300g is that it cannot do depth clamping without disabling
the clipping entirely. There is only one big switch called CLIP_DISABLE, which
"Disables cli
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #31 from Henri Verbeet ---
You're mixing things up a bit, the functionality this bug is about is mostly
controlled by D3DRS_ZENABLE in d3d9. Considering only pre-transformed
(D3DFVF_XYZRHW) vertices, the behaviour is like this:
- Wh
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #30 from Christoph Bumiller ---
How does it depend on the depth test, and why does it seem "off" to make
something that is originally a shader property in D3D a shader property in
OpenGL as well ?
Not using shaders isn't allowed (at l
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #32 from Marek Olšák ---
There would be no advantage for r300g.
The problem with r300g is that it cannot do depth clamping without disabling
the clipping entirely. There is only one big switch called CLIP_DISABLE, which
"Disables cli
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #31 from Henri Verbeet ---
You're mixing things up a bit, the functionality this bug is about is mostly
controlled by D3DRS_ZENABLE in d3d9. Considering only pre-transformed
(D3DFVF_XYZRHW) vertices, the behaviour is like this:
- Wh
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #30 from Christoph Bumiller ---
How does it depend on the depth test, and why does it seem "off" to make
something that is originally a shader property in D3D a shader property in
OpenGL as well ?
Not using shaders isn't allowed (at l
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #29 from Stefan D?singer ---
Hmm, this seems like an idea worth thinking about. The D3D behavior the
proposed extension addresses is part of the D3DDECLUSAGE_POSITIONT /
D3DFVF_XYZRHW vertex input semantics.
For now I'm opposed to ma
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #29 from Stefan Dösinger ---
Hmm, this seems like an idea worth thinking about. The D3D behavior the
proposed extension addresses is part of the D3DDECLUSAGE_POSITIONT /
D3DFVF_XYZRHW vertex input semantics.
For now I'm opposed to ma
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #28 from Marek Ol??k ---
Stefan, is the extension for implementing the POSITIONT shader semantic? Would
a gl_Position output modifier also work for you?
For example:
#extension GL_MESA_xxx : require
pretransformed gl_Position;
voi
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #28 from Marek Olšák ---
Stefan, is the extension for implementing the POSITIONT shader semantic? Would
a gl_Position output modifier also work for you?
For example:
#extension GL_MESA_xxx : require
pretransformed gl_Position;
voi
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #27 from Stefan D?singer ---
This is a bad idea because Wine can also run OpenGL applications, which might
use depth_clamp in a way that doesn't work on r300g.
Feel free to revert the patch for now. Implementing MESA_depth_clip is fa
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #27 from Stefan Dösinger ---
This is a bad idea because Wine can also run OpenGL applications, which might
use depth_clamp in a way that doesn't work on r300g.
Feel free to revert the patch for now. Implementing MESA_depth_clip is fa
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #26 from Marek Ol??k ---
Stefan> We can also go the easy way and only advertise ARB_depth_clamp if the
user is Wine. It would work in the same way we disable HyperZ for compositors.
I'm assuming Wine can be detected as easily as readi
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #26 from Marek Olšák ---
Stefan> We can also go the easy way and only advertise ARB_depth_clamp if the
user is Wine. It would work in the same way we disable HyperZ for compositors.
I'm assuming Wine can be detected as easily as readi
https://bugs.freedesktop.org/show_bug.cgi?id=57875
Piero Finizio changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=57875
Piero Finizio changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #24 from Piero Finizio ---
P.S.
System Software / Hardware Information
Hardware:
Processor: Intel Core Duo T2350 @ 1.86GHz (2 Cores),Graphics: AMD Mobility
Radeon X1700 M66 RV535 256MB
Software:
OS: Fedora 18 (Spherical Cow), Kern
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #23 from Piero Finizio ---
Bisecting is difficult because almost every day I compile from git but i
change mesa/drm and xorg/driver/xf86-video-ati in ensemble...
Plus I compiled on Fedora 18 with 3.7.x-xx kernel that carries power
m
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #24 from Piero Finizio ---
P.S.
System Software / Hardware Information
Hardware:
Processor: Intel Core Duo T2350 @ 1.86GHz (2 Cores),Graphics: AMD Mobility
Radeon X1700 M66 RV535 256MB
Software:
OS: Fedora 18 (Spherical Cow), Kern
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #23 from Piero Finizio ---
Bisecting is difficult because almost every day I compile from git but i
change mesa/drm and xorg/driver/xf86-video-ati in ensemble...
Plus I compiled on Fedora 18 with 3.7.x-xx kernel that carries power
m
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #22 from Stefan D?singer ---
Are you sure? I see nothing in the r300g git history that I'd expect to have
fixed this bug. Unless of course the hw does what ARB_depth_clamp requires when
you set CLIP_DISABLE and the rendering problems
https://bugs.freedesktop.org/show_bug.cgi?id=57875
Piero Finizio changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #22 from Stefan Dösinger ---
Are you sure? I see nothing in the r300g git history that I'd expect to have
fixed this bug. Unless of course the hw does what ARB_depth_clamp requires when
you set CLIP_DISABLE and the rendering problems
https://bugs.freedesktop.org/show_bug.cgi?id=57875
Piero Finizio changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #20 from Marek Ol??k ---
FWIW, the extension specification looks good to me.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #19 from Stefan D?singer ---
Are there any comments on the 2nd extension spec? If it looks good to you I'll
do some tests with the r200 and r500 GPUs I have to see how unclipped Z values
behave in fragment processing to make sure the
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #20 from Marek Olšák ---
FWIW, the extension specification looks good to me.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #19 from Stefan Dösinger ---
Are there any comments on the 2nd extension spec? If it looks good to you I'll
do some tests with the r200 and r500 GPUs I have to see how unclipped Z values
behave in fragment processing to make sure the
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #18 from Piero Finizio ---
If i try to revert the commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 (above
mentioned workaround) with git
"HEAD at 7c35521 mesa: add missing texel fetch code for sRGB DXT formats"
the compilation ends wi
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #18 from Piero Finizio ---
If i try to revert the commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 (above
mentioned workaround) with git
"HEAD at 7c35521 mesa: add missing texel fetch code for sRGB DXT formats"
the compilation ends wi
https://bugs.freedesktop.org/show_bug.cgi?id=57875
Stefan D?singer changed:
What|Removed |Added
Attachment #71244|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=57875
Stefan Dösinger changed:
What|Removed |Added
Attachment #71244|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #16 from Henri Verbeet ---
(In reply to comment #15)
> I've written an extension proposal for a new mesa extension that exposes the
> CLIP_DISABLE bit. The proposal is attached, please review and comment. There
> are some TODOs I'm no
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #16 from Henri Verbeet ---
(In reply to comment #15)
> I've written an extension proposal for a new mesa extension that exposes the
> CLIP_DISABLE bit. The proposal is attached, please review and comment. There
> are some TODOs I'm no
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #15 from Stefan D?singer ---
Created attachment 71244
--> https://bugs.freedesktop.org/attachment.cgi?id=71244&action=edit
proposed MESA_clip_disable extension
I've written an extension proposal for a new mesa extension that expose
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #15 from Stefan Dösinger ---
Created attachment 71244
--> https://bugs.freedesktop.org/attachment.cgi?id=71244&action=edit
proposed MESA_clip_disable extension
I've written an extension proposal for a new mesa extension that expose
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #14 from Marek Ol??k ---
(In reply to comment #10)
> > That bit only exists on r5xx asics. R3xx and r4xx don't have that bit.
> I'd say it's related to floating point depth buffer support. I don't know
> about the capabilities of the
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #13 from Stefan D?singer ---
I think a new extension is the way to go. We could probably call it
GL_MESA_depth_clip_disable or GL_MESA_depth_clamp_d3d.
One could try to combine the CLIP_DISABLE register with clamping gl_FragDepth
ins
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #12 from Henri Verbeet ---
(In reply to comment #9)
> 1) Wine shouldn't use ARB_depth_clamp, but instead it should use an
> extension that exposes CLIP_DISABLE as defined by D3D9 to the user. The
> problem is such an extension doesn't
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #11 from Stefan D?singer ---
I found the r500 register docs, and yeah, the Z_EXTENDED bit sounds less useful
now...
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #10 from Stefan D?singer ---
(In reply to comment #8)
> That bit only exists on r5xx asics. R3xx and r4xx don't have that bit.
I'd say it's related to floating point depth buffer support. I don't know about
the capabilities of the GP
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #9 from Marek Ol??k ---
I don't remember having anything useful besides some quick hacks and I don't
have them anymore. I came to the conclusion ARB_depth_clamp is not
implementable on r300-r500. I don't think the extended range [-2,2
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #8 from Alex Deucher ---
(In reply to comment #7)
> Aw, of course thr R3xx_3D_Registers.pdf document doesn't document bit 24 of
> R300_GB_TILE_CONFIG, which supposedly contains the Z_EXTENDED flag...
That bit only exists on r5xx asic
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #7 from Stefan D?singer ---
Aw, of course thr R3xx_3D_Registers.pdf document doesn't document bit 24 of
R300_GB_TILE_CONFIG, which supposedly contains the Z_EXTENDED flag...
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #6 from Stefan D?singer ---
I can reproduce the bug, and after a quick investigation it seems to be a
legitimate problem how depth clamping is handled. The application enables it,
it enables it only if the extension is available and i
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #5 from Piero Finizio ---
http://sldev.free.fr/
The stable branch Linux: CoolVLViewer-1.26.4.XX works with r300,
the CoolVLViewer-1.26.5.XX doesn't because it derives from Second Life
official viewer series 3 and so suffers from th
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #4 from Stefan D?singer ---
I'll have a look at it once I find a download for this app.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbe
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #14 from Marek Olšák ---
(In reply to comment #10)
> > That bit only exists on r5xx asics. R3xx and r4xx don't have that bit.
> I'd say it's related to floating point depth buffer support. I don't know
> about the capabilities of the
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #13 from Stefan Dösinger ---
I think a new extension is the way to go. We could probably call it
GL_MESA_depth_clip_disable or GL_MESA_depth_clamp_d3d.
One could try to combine the CLIP_DISABLE register with clamping gl_FragDepth
ins
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #12 from Henri Verbeet ---
(In reply to comment #9)
> 1) Wine shouldn't use ARB_depth_clamp, but instead it should use an
> extension that exposes CLIP_DISABLE as defined by D3D9 to the user. The
> problem is such an extension doesn't
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #11 from Stefan Dösinger ---
I found the r500 register docs, and yeah, the Z_EXTENDED bit sounds less useful
now...
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #10 from Stefan Dösinger ---
(In reply to comment #8)
> That bit only exists on r5xx asics. R3xx and r4xx don't have that bit.
I'd say it's related to floating point depth buffer support. I don't know about
the capabilities of the GP
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #9 from Marek Olšák ---
I don't remember having anything useful besides some quick hacks and I don't
have them anymore. I came to the conclusion ARB_depth_clamp is not
implementable on r300-r500. I don't think the extended range [-2,2
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #8 from Alex Deucher ---
(In reply to comment #7)
> Aw, of course thr R3xx_3D_Registers.pdf document doesn't document bit 24 of
> R300_GB_TILE_CONFIG, which supposedly contains the Z_EXTENDED flag...
That bit only exists on r5xx asic
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #7 from Stefan Dösinger ---
Aw, of course thr R3xx_3D_Registers.pdf document doesn't document bit 24 of
R300_GB_TILE_CONFIG, which supposedly contains the Z_EXTENDED flag...
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #6 from Stefan Dösinger ---
I can reproduce the bug, and after a quick investigation it seems to be a
legitimate problem how depth clamping is handled. The application enables it,
it enables it only if the extension is available and i
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #5 from Piero Finizio ---
http://sldev.free.fr/
The stable branch Linux: CoolVLViewer-1.26.4.XX works with r300,
the CoolVLViewer-1.26.5.XX doesn't because it derives from Second Life
official viewer series 3 and so suffers from th
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #4 from Stefan Dösinger ---
I'll have a look at it once I find a download for this app.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #3 from Piero Finizio ---
Yes, reverting commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 works.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #2 from Marek Ol??k ---
Does reverting the commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 help?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment wa
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #1 from Piero Finizio ---
Created attachment 70995
--> https://bugs.freedesktop.org/attachment.cgi?id=70995&action=edit
The "blue triangles"
--
You are receiving this mail because:
You are the assignee for the bug.
--
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #3 from Piero Finizio ---
Yes, reverting commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 works.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mail
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #2 from Marek Olšák ---
Does reverting the commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 help?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mai
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #1 from Piero Finizio ---
Created attachment 70995
--> https://bugs.freedesktop.org/attachment.cgi?id=70995&action=edit
The "blue triangles"
--
You are receiving this mail because:
You are the assignee for the bug.
___
66 matches
Mail list logo