Hey there,
I'm experiencing some performance problems with wined3d. The affected
game is FEAR (demo does the trick). At first I thought it was related to
running the demo on my Intel i965, but I got the same problem running
the demo on my Radeon HD4750@r600g.
If anyone wants to test this
I'm not entirely sure on how to do this properly. Making it an ERR
would be too loud for applications that never use s3tc textures, as a
WARN it's never going to be seen unless you look at the debug channel.
Printing a message in wined3d in CreateSurface() would probably work,
but the resulting
*hint* *hint* See the commit message!
It's very easy. Only ordinary sampling is supported, because I have no
application which I can use to test the others variants (only support
the features you can actually test).
Won't work since the GL_LIMITS macro is defined in this way:
#define GL_LIMITS(ExtName)(GLINFO_LOCATION.max_##ExtName)
I don't think changing the variable name is an option, since keeping
consistency there should be priority:
ps_arb_max_local_constants - ??? (I don't think it's wise
You can find the current patchset here:
http://www.math.uni-bielefeld.de/~tjakobi/wine/np2fixup_arb/
Of course the GLSL patchset is needed as well:
http://www.math.uni-bielefeld.de/~tjakobi/wine/np2fixup_glsl/
I hope both can finally go into master, so please take a look.
Going to resend the
Hi Henri,
I do this for patch 3/4, otherwise the code gets kinda ugly.
A good point probably is that the code is indeed rarely used, since it
was written specifically for the FX generation. So it makes sense to
skip it early - put it into a seperate loop and conceal it with an
if-statement.
Like
Actually that comment was about the state change trouble NP2 fixups cause
-
since we can ignore the additional state handlers needed to adjust the TF2
matrices and call the NP2 constant load code, the NP2 code doesn't add
much
burden if its not used.
OK, I see. But the same reason should
James McKenzie wrote:
Tobias Jakobi wrote:
For review:
This patchset implements np2 texcoord fixup in ARB mode. Constants used to
store texture dimensions are already packed, using the same data structures
like the GLSL packing code.
The code is finished and works quite well. It has been
Stefan Dösinger wrote:
Am Donnerstag, 23. April 2009 14:54:54 schrieb Tobias Jakobi:
NAK
Suggestions? Explanations?
Like explained putting this into prog_link won't work. It doesn't make
sense in the first place.
Using a separate struct for GLSL and ARB isn't also making sense, since
Stefan Dösinger wrote:
I think Henri is generally against adding something to the
ps_compiled_shader structure - but I might be wrong there.
However I don't know how to implement the code without introducing new
data to ps_compiled_shader.
No, he doesn't like having this info visible outside
NAK
Suggestions? Explanations?
Like explained putting this into prog_link won't work. It doesn't make
sense in the first place.
Using a separate struct for GLSL and ARB isn't also making sense, since
the data stored in the struct is independant of GLSL and ARB.
- I'm sure I mentioned this before, but please don't add code without
using it.
I'll merge it with one of the other patches then.
- Why is this in struct ps_compiled_shader? This really looks like
something that should be internal to the backend.
No, that's definitely not the case.
The
However the FX only supports these 256 constants and every other NV card
above the FX doesn't need the fixup since ARB_texture_non_power_of_two
is supported in hardware.
This was my thought when limiting the index array to uchars. I know that
you mentioned we could use the fixup code also for
Henri Verbeet wrote:
2009/4/22 Tobias Jakobi liquid.a...@gmx.net:
- Why is this in struct ps_compiled_shader? This really looks like
something that should be internal to the backend.
No, that's definitely not the case.
The struct's data is used both in GLSL and ARB mode (I'll submit the ARB
Henri Verbeet wrote:
A handle table would probably make the most sense. A pointer would
work for ARB, but for GLSL that's just extra indirection that isn't
really needed.
Sry, I have to correct myself.
It won't work that way.
Setting up the data of the np2 fixup data struct is done in
Henri Verbeet wrote:
Tex fixup parameter for tex1 would have idx 0, the one for tex3 would
have idx 1. These would then be packed as PsamplerNP2Fixup0.xy and
PsamplerNP2Fixup0.zw.
OK, forget that as well.
Like I replied to Stefan about the uchar thing: The code is only active
for FX cards
For review:
This patchset implements np2 texcoord fixup in ARB mode. Constants used to
store texture dimensions are already packed, using the same data structures
like the GLSL packing code.
The code is finished and works quite well. It has been tested with Max Payne 2,
HL2 and FEAR. All
--
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss
für nur 17,95 Euro/mtl.!*
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
0002--wined3d-shader_generate_arb_declarations-add-NP2.patch
Description: Binary data
--
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss
für nur 17,95 Euro/mtl.!*
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
0004--wined3d-implement-shader_arb_load_np2fixup_constan.patch
Description: Binary data
--
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss
für nur 17,95 Euro/mtl.!*
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
0006--wined3d-force-constant-reload-for-NP2-fixup-in-sha.patch
Description: Binary data
--
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger01
0003--wined3d-shader_hw_sample-add-NP2-fixup-code.patch
Description: Binary data
--
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger01
0007--wined3d-correct-now-faulty-comment.patch
Description: Binary data
--
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger01
0005--wined3d-remove-comment-about-np2fixup-not-implemen.patch
Description: Binary data
It's either the handling of zero times +infty or the handling of NaN
(how is NaN mapped to a RGBA vector?). OpenGL and D3D do seems to have
different opinions on how this should be done.
On OpenGL there is no word in the standard how it should be done, so
it's essentially undefined behaviour. The
It's also affecting one of my bugs:
http://bugs.winehq.org/show_bug.cgi?id=15858
It's sort of random when a real crash occurs but the debugging revealed
that the object that is used was already freed by wined3d.
I can increase the probability of a crash by running a bunch of
memory-hungry apps
Stefan Dösinger wrote:
If you know which patch might have broken this, start there. If you do
not, a normal regression test is a good idea.
It will always be the last patch. This patch does the real thing, the others
are just making the infrastructure more flexible. So a regression test in
Short feedback:
- Max Payne 2: works as expected, I don't see any visual changes
- Morrowind: 3D rendering breaks completly, minor (blending?) issues in
the menu as well - however ingame scenes are fully black now
How should I report this? Open a bug? Should I do any regression testing
(since
Stefan Dösinger wrote:
I'm sorry, I cannot reproduce this. Which settings are you using?
I see it now, it only occurs with medium post processing settings.
OK, I can't use the high settings for now because of the slowdowns.
Medium is the only half-working option for now.
The patch obviously
Intended, see patch 2/3 - the testcase is activated there (since it pass
then).
Posted a alternate version of the patchset to wine-patches, now using
todo_wine and activating the testcase in the first patch.
Patch no. 3 didn't change though, but I reposted it anyway.
Greets,
Tobias
(I think this belongs into wine-devel, sorry for also posting this on
wine-patches)
Oops, sorry! I corrected the mixed indentation style (must have been the
copypaste).
However I think the comment should stay there. I don't think the MSDN
docs are updated in the near future, at least what
32 matches
Mail list logo
