[PATCH v2 1/5] wined3d: Introduce wined3d_device_apply_stateblock(). (original) (raw)
Zebediah Figura z.figura12 at gmail.com
Fri Dec 13 09:53:35 CST 2019
- Previous message (by thread): [PATCH v2 1/5] wined3d: Introduce wined3d_device_apply_stateblock().
- Next message (by thread): [PATCH v2 1/6] strmbase: Check for a NULL media type in IPin::ReceiveConnection().
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 12/12/19 7:22 AM, Henri Verbeet wrote:
On Wed, 11 Dec 2019 at 07:16, Zebediah Figura <z.figura12 at gmail.com> wrote:
+ wined3ddevicesetvsconstsf(device, 0, d3dinfo->limits.vsuniformcount, state->vsconstsf); + wined3ddevicesetvsconstsb(device, 0, WINED3DMAXCONSTSB, state->vsconstsb); + wined3ddevicesetvsconstsi(device, 0, WINED3DMAXCONSTSI, state->vsconstsi); + wined3ddevicesetpsconstsf(device, 0, d3dinfo->limits.psuniformcount, state->psconstsf); + wined3ddevicesetpsconstsb(device, 0, WINED3DMAXCONSTSB, state->psconstsb); + wined3ddevicesetpsconstsi(device, 0, WINED3DMAXCONSTSI, state->psconstsi); + That's going to invalidate every constant on every draw, even if none of them changed, which seems undesirable. It shouldn't be too hard to extract ranges from the "changed" info, although ideally changed float constants would be stored in a proper bitmap first.
Sure, I can try for that. I admittedly don't have a great idea of the tradeoffs and bottlenecks involved here, so a bit of clarification would also be appreciated.
- Previous message (by thread): [PATCH v2 1/5] wined3d: Introduce wined3d_device_apply_stateblock().
- Next message (by thread): [PATCH v2 1/6] strmbase: Check for a NULL media type in IPin::ReceiveConnection().
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]