Hi,
In the past days I've been hacking on implementing my state management ideas,
and I think I've come to a state where I don't have to be completely ashamed
of my patches :-)
First, what the code does NOT do yet:
* Pixel Shaders, GLSL shaders: I only had my notebook with the M9 available,
so
Hi I cant compile it with actual CVS head.
drawprim.o: In function `drawPrimitive':
/usr/src/wine/dlls/wined3d/drawprim.c:1696: undefined reference to
`list_move'
collect2: ld returned 1 exit status
winegcc: gcc failed.
make: *** [wined3d.dll.so] Error 2
Mirek
Stefan Dösinger napsal(a):
Hi,
Am Montag 27 November 2006 12:02 schrieben Sie:
Hi I cant compile it with actual CVS head.
drawprim.o: In function `drawPrimitive':
/usr/src/wine/dlls/wined3d/drawprim.c:1696: undefined reference to
`list_move'
collect2: ld returned 1 exit status
winegcc: gcc failed.
make: ***
On 27/11/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Ah yeah, The list_move thing is outside of wined3d. The attached patch is
needed. I think I'll send that patch to wine-patches too.
Warning, the patch causes a full wine recompile because nearly every lib uses
list.h
Shouldn't you just
Am Montag 27 November 2006 13:36 schrieben Sie:
Here is log from 3DMark 2005, some new games are not working with those
patches, 3DMark 2001 works but very bad in high details tests.
05 fails because of pixel shaders / glsl, and I know that 2001 is broken
because my patch doesn't care for
I had a very brief look at the code, pertially because a tarred up
directory isn't the most convenient way to spot what has changed and
what is still the same.
A few things I noticed:
- markDirty() should probably either be a proper method of the
device, or have a prefix
- States is a pretty
On 27/11/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Am Montag 27 November 2006 13:36 schrieben Sie:
Here is log from 3DMark 2005, some new games are not working with those
patches, 3DMark 2001 works but very bad in high details tests.
05 fails because of pixel shaders / glsl,
Eh? 3DMark05
Am Montag 27 November 2006 14:47 schrieben Sie:
On 27/11/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Am Montag 27 November 2006 13:36 schrieben Sie:
Here is log from 3DMark 2005, some new games are not working with those
patches, 3DMark 2001 works but very bad in high details tests.
Am Montag 27 November 2006 13:04 schrieb H. Verbeet:
I had a very brief look at the code, pertially because a tarred up
directory isn't the most convenient way to spot what has changed and
what is still the same.
I can of course send you my 45 patches too, but they are pretty messy because
I
Am Montag 27 November 2006 13:07 schrieb H. Verbeet:
On 27/11/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Ah yeah, The list_move thing is outside of wined3d. The attached patch is
needed. I think I'll send that patch to wine-patches too.
Warning, the patch causes a full wine recompile
It is working, only demo version (you cant use full version), and only
demo can run on my system with GLSL.
Mirek
H. Verbeet napsal(a):
On 27/11/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Am Montag 27 November 2006 13:36 schrieben Sie:
Here is log from 3DMark 2005, some new games are not
On 27/11/06, Mirek [EMAIL PROTECTED] wrote:
It is working, only demo version (you cant use full version), and only
demo can run on my system with GLSL.
Mirek
Ah yes, I think Tom mentioned that the demo does work. I was thinking
about the actual game tests.
I do know what caps it needs, and
On 27/11/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Am Montag 27 November 2006 13:04 schrieb H. Verbeet:
I had a very brief look at the code, pertially because a tarred up
directory isn't the most convenient way to spot what has changed and
what is still the same.
I can of course send you
Am Montag 27 November 2006 16:20 schrieben Sie:
I'm not directly opposed to the current setup, it's more that I'm
wondering if going for separate tables for related states would
perhaps result in cleaner / more flexible code. It would of course
allow you to get rid of those macros :-)
Not so
Stefan Dösinger wrote:
* sRGB textures: Dirtifies the sampler. All textures have now information
about how many samplers they are bound to, and the number of one of the
samplers. Phil?
Stefan
I still have my sRGB patch but haven't been working on it mainly just
because I've been busy with
Can you describe what this would look like in detail
I haven't thought it through in detail - just making sure you have. I
think you're going in the right direction, as long as considering things
other than render states in the design - won't bother you anymore, until
I see some more of
Am Montag 23 Oktober 2006 00:57 schrieben Sie:
What does addDirtyState() do when called multiple times with the same
representative?
There is a stateblock-changed.somestate field in the stateblock, which is a
boolean right now. This can be made a pointer to the list element, and set to
the
Stefan Dösinger wrote:
Am Montag 23 Oktober 2006 00:57 schrieben Sie:
What does addDirtyState() do when called multiple times with the same
representative?
There is a stateblock-changed.somestate field in the stateblock, which is a
boolean right now. This can be made a pointer to the
On 23/10/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
How would I mark vertex shader constant #3653 dirty, and apply it using
your mechanism ?
Uhh, shader constants, must have forgotten them :-( . Well, Henri and I
silently agreed to leave them as they are right now. I think they have a
On 23/10/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
Uhh, shader constants, must have forgotten them :-( . Well, Henri and I
silently agreed to leave them as they are right now.
I don't like how the number of things staying as they are right now is
growing, while the number of things being
Am Montag 23 Oktober 2006 08:43 schrieben Sie:
Stefan Dösinger wrote:
Am Montag 23 Oktober 2006 00:57 schrieben Sie:
What does addDirtyState() do when called multiple times with the same
representative?
There is a stateblock-changed.somestate field in the stateblock, which
is a
Hi,
One issue with shader constants is that in GLSL you set uniforms per
program object, and it keeps the values last set, also when changing
the currently used program. That means that in certain cases we might
be setting constants to the same values as they were the last time we
used the
I don't like how the number of things staying as they are right now is
growing, while the number of things being changed remains confined to
render states. To have a proof-of-concept state management system, it
would be best to take things that are as different as possible, and
manage to get
Because that creates confusion and disorder - the idea is to move from
chaos (gl code in drawprim, shaders, device.c) to order (gl code in one
place, following a uniform pattern, with the ability to do locking
and/or switch the gl backend).
Well, there is not much difference between samplers,
Jaap Stolk wrote:
On 10/22/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
and we loose the ability to
set up a constant table in the code.
The constant table is usually a bad idea, and this demonstrates why -
I'm in favor of flexibility, but is it correct to assume that the
number of functions
n0dalus wrote:
On 10/22/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
Constant is convenient, but if it can't meet all necessary requirements,
I wouldn't hesitate to drop the idea - never compromise on design in
favor of C optimizations. Tomorrow's hardware will make any
non-algorithmic
Am Sonntag 22 Oktober 2006 10:31 schrieben Sie:
Warning: Lots of rant following, for the specific answers on ivg2's concerns
see the end of the mail
n0dalus wrote:
On 10/22/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
Constant is convenient, but if it can't meet all necessary requirements,
Am Sonntag 22 Oktober 2006 10:31 schrieb Ivan Gyurdiev:
I thought that my first reply was a bit off-topic, I think I should describe
my idea with the table a bit better :-)
Each entry in the state table has 2 fields. They do not strictly depend on
each other:
struct StateEntry
{
DWORD
device-addDirtyState(This, States[State]-representative)
This way the code applying the states has to be called only once.
What does addDirtyState() do when called multiple times with the same
representative?
This is still a bunch of code, not a magic instruction how to call gl
On 10/22/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote:
Constant is convenient, but if it can't meet all necessary requirements,
I wouldn't hesitate to drop the idea - never compromise on design in
favor of C optimizations. Tomorrow's hardware will make any
non-algorithmic optimizations irrelevant.
Am Freitag 20 Oktober 2006 02:24 schrieben Sie:
More?
What are your plans for dealing with these:
=
SetLight()
SetLightEnable()
Depens on wether lights are shared with share lists. If yes, leave them as
they are, otherwise put them on the list
SetTexture()
Manage
Am Freitag 20 Oktober 2006 00:04 schrieb H. Verbeet:
Well, the number of sampler stages (and thus the number of sampler
stage states) for example is dependant on hardware limits, so you
can't really use the #define STATE_SAMPLER(b, a)
STATE_RENDER(WINEHIGHEST_RENDER_STATE +
On 20/10/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
include/wine/wined3d_types.h
#define WINED3D_HIGHEST_SAMPLER_STATE WINED3DSAMP_DMAPOFFSET
WINED3DSAMP_DMAPOFFSET = 13,
Those are per stage.
and dlls/wined3d/wined3d_private.h
#define MAX_SAMPLERS 16
That's the maximum d3d9
Hi
and dlls/wined3d/wined3d_private.h
#define MAX_SAMPLERS 16
That's the maximum d3d9 supports, not necessarily what the hardware
can do. Unsupported samplers would be wasted. Worse, d3d10 will
support a lot more than 16 samplers.
Right, we would waste 13*8 = 104 bytes per unsupported
On 20/10/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Right, we would waste 13*8 = 104 bytes per unsupported sampler. How much
samplers does d3d10 support?
Something like 128.
If we use run-time dynamic values for the state table then we loose the
ability to access a state with its state
Am Freitag 20 Oktober 2006 11:15 schrieb H. Verbeet:
On 20/10/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Right, we would waste 13*8 = 104 bytes per unsupported sampler. How much
samplers does d3d10 support?
Something like 128.
128 is big, agreed.
If we use run-time dynamic values for
On 20/10/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Hmm, the sampler states are per sampler in d3d, and per texture object in gl
as far as I know. So we have to find some way if the sampler states are
changed regarding the texture used for drawing. This is getting tricky :-/
Yes, sRGB support
Am Freitag 20 Oktober 2006 12:00 schrieb H. Verbeet:
On 20/10/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Hmm, the sampler states are per sampler in d3d, and per texture object in
gl as far as I know. So we have to find some way if the sampler states
are changed regarding the texture used
Yes, sRGB support has a problem with that as well.
Things like sRGB where the concept of activating it is entirely different
between d3d and opengl won't fit into the state management anyway. We will
have to take care for sRGB in SetTexture, SetSamplerState and maybe
Hi,
I considererd that it would be finally time to get started with the state
management rewrite :-) Just a mail with the final plan, if anyone has
comments.
I will move the functions applying the states into a new file,
opengl_utils.c(name inspired by old ddraw). I don't want to put them into
On 19/10/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
I will move the functions applying the states into a new file,
opengl_utils.c(name inspired by old ddraw). I don't want to put them into
drawprim.c because that file is already quite long.
Not sure about the _utils part there, since it's
Not sure about the _utils part there, since it's pretty much core
functionality, but fair enough.
well, we can use other names too :-) opengl_state.c, opengl_AllOtherStuff.c
vertex type) will share the same list. The index of the changed state
will identify the type of the state, e.g.
States will be applied in drawprim. BltOverride and UnlockRect change states
on their own, and they can put the states the change onto the dirty list so
drawprim will reset them to what the application wants.
What about Clear()?
Maybe you should also provide the capability of applying a
States will be applied in drawprim.
It will be good if *all* texture-related states were applied in
drawprim, specifically. This is a prerequisite to VTF support, since
that involves repacking pixel and vertex textures into a single array,
and changing their indices [ should happen at
Am Donnerstag 19 Oktober 2006 13:35 schrieb Ivan Gyurdiev:
States will be applied in drawprim.
It will be good if *all* texture-related states were applied in
drawprim, specifically. This is a prerequisite to VTF support, since
that involves repacking pixel and vertex textures into a single
Am Donnerstag 19 Oktober 2006 12:08 schrieb Stefan Dösinger:
Hi,
I considererd that it would be finally time to get started with the state
management rewrite :-) Just a mail with the final plan, if anyone has
comments.
Well, I started with the thing, and I want to show the first results so
Well, the number of sampler stages (and thus the number of sampler
stage states) for example is dependant on hardware limits, so you
can't really use the #define STATE_SAMPLER(b, a)
STATE_RENDER(WINEHIGHEST_RENDER_STATE +
WINEHIGHEST_SAMPLER_STATE * b + a) macro since
WINEHIGHEST_SAMPLER_STATE
More?
What are your plans for dealing with these:
=
SetLight()
SetLightEnable()
SetTexture()
SetDepthStencilBuffer()
SetRenderTarget()
SetSomethingElseThatsNotARenderState().
+for (j = 0; j GL_LIMITS(textures); i++) {
+for (i = 0; i NUM_SAVEDPIXELSTATES_T; i++) {
+object-changed.textureState[j][SavedPixelStates_T[i]] = TRUE;
+}
+}
This looks like a loop counter bug...
+for (j = 0; j
49 matches
Mail list logo
