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 th
> 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 sampler
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 t
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 th
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. field in the stateblock, which
> > is 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
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
sim
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. field in the stateblock, which is a
boolean right now. This can be made a pointer to the list elem
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. field in the stateblock, which is a
boolean right now. This can be made a pointer to the list element, and set to
the element w
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
directl
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
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 requirem
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 optimiza
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 functio
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 that won't work
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
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 -
the texture format table is another one where somehow we've been able to
get away with staying constant, but I am sure issues will show up in the
future invol
> > 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
> ApplyStateBlock(d
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 textu
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 suppor
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 va
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 num
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 unsu
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 supp
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 +
> WINEHIGHEST_S
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()
More?
What are your plans for dealing with these:
=
SetLight()
SetLightEnable()
SetTexture()
SetDepthStencilBuffer()
SetRenderTarget()
SetSomethingElseThatsNotARenderState().
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 w
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
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 si
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 drawpri
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 single
> 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.
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 pr
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
35 matches
Mail list logo
