Re: [Mesa3d-dev] empty vertex buffers
On Fri, Feb 5, 2010 at 2:46 PM, Joakim Sindholt b...@zhasha.com wrote: Let's assume I have an array of vertex elements that indicate position/color in vertex buffer #3. Let's also for the sake of argument say that there is nothing else in my vertex elements. No other buffers are being pointed to. Is it legal for me to pipe_context::set_vertex_buffers with an array size of 3 and set buffer 1 and 2 == NULL? Not to mention buffer 0... At the moment I'd say that, yes this is permitted. I'm not sure if there is any state-tracker out there that really wants to be able to do this, though, so it is something we could look at tightening up if it is causing real pain at the driver level. Keith -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] gallium-cylindrical-wrap branch
On Fri, Feb 5, 2010 at 5:29 PM, Brian Paul bri...@vmware.com wrote: michal wrote: michal wrote on 2010-02-05 11:05: Brian Paul wrote on 2010-02-04 22:07: michal wrote: Brian Paul wrote on 2010-02-03 17:58: Keith Whitwell wrote: Michal, why do you need this for linear interpolator and not perspective? I think d3d mobile let you disable perspective correct texturing, but it is always enabled for normal d3d. I could not think of a use case that uses perspective and cylindrical interpolation at the same time. If you think it's valid, we can implement cylindrical wrapping for perspective interpolator, but then I am not sure how exactly it should be done, i.e. should we divide and then wrap or the opposite? Is there some way we can figure out what DX9 does here? Maybe a quick test? I suspect cylindrical wrapping would be done after the divide. A quick test shows it is legal to have perspective and cylindrical interpolation. In fact, I see no difference between projected and non-projected version with REF device -- both are perspective correct. I think I am stuck at this point and need further help. I am trying to modify tri_persp_coeff() in softpipe in a similar manner to tri_linear_coeff(), but all I get are lousy rendering artifacts. If we need do cylindrical wrapping after divide, it must be done as part of shader interpolator, but the only place where we have enough information to do wrapping is in primitive setup. Do you have a patch relative to gallium-cylindrical-wrap? I'll take a look. Brian, I have no half-working patch for you, sorry. I tried a few approaches, but they were nonsensical. The linear coeff calculation is simple: calculate distance between two coordinates, and if it's greater than 0.5, apply wrapping by adjusting the distance. However, for the perspective correct coeffs, we divide early by position.w before calculating the distance, and so my approach that worked for linear fails here. I am either not comprehending the math here (why do we divide the second time in interpolator, for instance?) or we need to put more information into struct tgsi_interp_coef so that the interpolator code has enough information to do wrapping on its own without help of primitive setup. OK, I managed to correctly implement cylindrical wrap in softpipe both for linear and perspective interpolation, both for lines and triangles. Tested with Brian's cylwrap test app -- it works. Please re-review. Thanks. Seems to work as expected. The code looks good. Thanks. -Brian I had one question about whether it's neccesary to do three wrapping calculations per triangle, or just two. Once that's resolved, I'm fine to see this merged. Keith -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] fix the usual cell breakage
also update the cell config a bit
---
configs/linux-cell |6 ++--
src/gallium/drivers/cell/common.h |3 +-
src/gallium/drivers/cell/spu/spu_per_fragment_op.c | 36 ++--
3 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/configs/linux-cell b/configs/linux-cell
index 221655c..229ac73 100644
--- a/configs/linux-cell
+++ b/configs/linux-cell
@@ -1,6 +1,6 @@
# linux-cell (non-debug build)
-include $(TOP)/configs/default
+include $(TOP)/configs/linux
CONFIG_NAME = linux-cell
@@ -25,10 +25,10 @@ OPT_FLAGS = -O3
SDK = /opt/cell/sdk/usr
-CFLAGS = $(OPT_FLAGS) -Wall -Winline -Wmissing-prototypes \
+CFLAGS = $(OPT_FLAGS) -mcpu=cell -Wall -Winline -Wmissing-prototypes \
-fPIC -m32 -std=c99 -mabi=altivec -maltivec \
-I. -I$(SDK)/include \
- -DGALLIUM_CELL -DUSE_XSHM -D_BSD_SOURCE -D_SVID_SOURCE
+ -DGALLIUM_CELL $(DEFINES)
CXXFLAGS = $(CFLAGS)
diff --git a/src/gallium/drivers/cell/common.h
b/src/gallium/drivers/cell/common.h
index aa29dcb..7f2b33c 100644
--- a/src/gallium/drivers/cell/common.h
+++ b/src/gallium/drivers/cell/common.h
@@ -36,7 +36,7 @@
#include pipe/p_compiler.h
#include pipe/p_format.h
#include pipe/p_state.h
-
+#include stdio.h
/** The standard assert macro doesn't seem to work reliably */
#define ASSERT(x) \
@@ -49,7 +49,6 @@
}
-
#define JOIN(x, y) JOIN_AGAIN(x, y)
#define JOIN_AGAIN(x, y) x ## y
diff --git a/src/gallium/drivers/cell/spu/spu_per_fragment_op.c
b/src/gallium/drivers/cell/spu/spu_per_fragment_op.c
index eba9f95..5328374 100644
--- a/src/gallium/drivers/cell/spu/spu_per_fragment_op.c
+++ b/src/gallium/drivers/cell/spu/spu_per_fragment_op.c
@@ -207,9 +207,9 @@ spu_fallback_fragment_ops(uint x, uint y,
* If we'll need the current framebuffer/tile colors for blending
* or logicop or colormask, fetch them now.
*/
- if (spu.blend.blend_enable ||
+ if (spu.blend.rt[0].blend_enable ||
spu.blend.logicop_enable ||
- spu.blend.colormask != 0xf) {
+ spu.blend.rt[0].colormask != 0xf) {
#if LINEAR_QUAD_LAYOUT /* See comments/diagram below */
fbc0 = colorTile-ui[y][x*2+0];
@@ -228,7 +228,7 @@ spu_fallback_fragment_ops(uint x, uint y,
/*
* Do blending
*/
- if (spu.blend.blend_enable) {
+ if (spu.blend.rt[0].blend_enable) {
/* blending terms, misc regs */
vector float term1r, term1g, term1b, term1a;
vector float term2r, term2g, term2b, term2a;
@@ -261,7 +261,7 @@ spu_fallback_fragment_ops(uint x, uint y,
/*
* Compute Src RGB terms (fragment color * factor)
*/
- switch (spu.blend.rgb_src_factor) {
+ switch (spu.blend.rt[0].rgb_src_factor) {
case PIPE_BLENDFACTOR_ONE:
term1r = fragR;
term1g = fragG;
@@ -310,7 +310,7 @@ spu_fallback_fragment_ops(uint x, uint y,
/*
* Compute Src Alpha term (fragment alpha * factor)
*/
- switch (spu.blend.alpha_src_factor) {
+ switch (spu.blend.rt[0].alpha_src_factor) {
case PIPE_BLENDFACTOR_ONE:
term1a = fragA;
break;
@@ -338,7 +338,7 @@ spu_fallback_fragment_ops(uint x, uint y,
/*
* Compute Dest RGB terms (framebuffer color * factor)
*/
- switch (spu.blend.rgb_dst_factor) {
+ switch (spu.blend.rt[0].rgb_dst_factor) {
case PIPE_BLENDFACTOR_ONE:
term2r = fbRGBA[0];
term2g = fbRGBA[1];
@@ -394,7 +394,7 @@ spu_fallback_fragment_ops(uint x, uint y,
/*
* Compute Dest Alpha term (framebuffer alpha * factor)
*/
- switch (spu.blend.alpha_dst_factor) {
+ switch (spu.blend.rt[0].alpha_dst_factor) {
case PIPE_BLENDFACTOR_ONE:
term2a = fbRGBA[3];
break;
@@ -427,7 +427,7 @@ spu_fallback_fragment_ops(uint x, uint y,
/*
* Combine Src/Dest RGB terms
*/
- switch (spu.blend.rgb_func) {
+ switch (spu.blend.rt[0].rgb_func) {
case PIPE_BLEND_ADD:
fragR = spu_add(term1r, term2r);
fragG = spu_add(term1g, term2g);
@@ -460,7 +460,7 @@ spu_fallback_fragment_ops(uint x, uint y,
/*
* Combine Src/Dest A term
*/
- switch (spu.blend.alpha_func) {
+ switch (spu.blend.rt[0].alpha_func) {
case PIPE_BLEND_ADD:
fragA = spu_add(term1a, term2a);
break;
@@ -527,29 +527,29 @@ spu_fallback_fragment_ops(uint x, uint y,
/*
* Do color masking
*/
- if (spu.blend.colormask != 0xf) {
+ if (spu.blend.rt[0].colormask != 0xf) {
uint cmask = 0x0; /* each byte corresponds to a color channel */
/* Form bitmask depending on color buffer format and colormask bits */
switch (spu.fb.color_format) {
case PIPE_FORMAT_A8R8G8B8_UNORM:
- if (spu.blend.colormask PIPE_MASK_R)
+ if (spu.blend.rt[0].colormask PIPE_MASK_R)
cmask |= 0x00ff; /* red */
- if
Re: [Mesa3d-dev] [Intel-gfx] [RFC] reduce number of visuals exposed by Intel drivers
On Fri, 05 Feb 2010 13:01:50 -0800, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to remove a bunch of the visuals and fbconfigs exposed by the Intel drivers. There are several categories of visuals that are likely not useful to anyone. A couple of our test suites (e.g., glean) like to run over every possible visual. As a result, the test suites take an extraordinary amount of time to run. I propose removing: * All 24-bit depth / 0-bit stencil visuals. These are compatible with the default state of a 24-bit depth / 8-bit stencil visual and offer no memory savings. This will eliminate 24 (of 72) visuals by itself. * All but one of the visuals with accumulation buffer. Accumulation is a software path in the Intel drivers (though this could be fixed), so I don't see any utility in offering multiple, optimized buffer configuration choices. This will eliminate an additional 23 visuals. This will leave the 25 visuals and 37 fbconfigs that are likely to be useful. Yes! pgppHpbqQmR94.pgp Description: PGP signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] [RFC] reduce number of visuals exposed by Intel drivers
On Sat, Feb 6, 2010 at 4:35 PM, Eric Anholt e...@anholt.net wrote: On Fri, 05 Feb 2010 13:01:50 -0800, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to remove a bunch of the visuals and fbconfigs exposed by the Intel drivers. There are several categories of visuals that are likely not useful to anyone. A couple of our test suites (e.g., glean) like to run over every possible visual. As a result, the test suites take an extraordinary amount of time to run. I propose removing: * All 24-bit depth / 0-bit stencil visuals. These are compatible with the default state of a 24-bit depth / 8-bit stencil visual and offer no memory savings. This will eliminate 24 (of 72) visuals by itself. * All but one of the visuals with accumulation buffer. Accumulation is a software path in the Intel drivers (though this could be fixed), so I don't see any utility in offering multiple, optimized buffer configuration choices. This will eliminate an additional 23 visuals. This will leave the 25 visuals and 37 fbconfigs that are likely to be useful. Yes! Wouldn't it be better to make piglit default to --quick for glean tests? Then add a switch to piglit runner that removes the quick option. If quick option doesn't test enough configs yes glean could select some 2 to 4 configs to test. But I don't oppose cleaning the fbconfig list. Specially when their value is questionable. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] call for testers: galllium-screen-context branch
On Fri, Feb 05, 2010 at 10:01:13AM +, Keith Whitwell wrote: We've had a couple of cleanups that we've wanted to do in gallium for as long as I can remember. One of which is to remove all the random context-creation calls and funnel them through something sensible like a context_create() call in pipe_screen. The gallium-screen-context branch does exactly that. The trouble is this change touches every driver and state-tracker in every combination. I can't even build half the drivers (what do I need to install to build nouveau?), let alone test them in any meaningful way. So, I really need people to take a look at this branch and make sure you can still at least build the driver, run some simple apps, etc. There is a typo in st/egl which Brian has fixed. Otherwise, it works great. -- o...@lunarg.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/2] Make GLX optional in libGL
On Fri, Feb 05, 2010 at 07:24:00PM -0500, Kristian Høgsberg wrote: These two patches move things around in GLX a bit. To make it possible to use libGL with EGL on framebuffer without pulling in X dependencies this patch make the GLX entry points and all the indirect API a ./configure time option. When disabled, libGL is essentially just glapi and needs libEGL to be useful. I had to go back to using a list of glapi object files instead of libglapi.a, since without the glx functions nothing is left to pull in the glapi files. Do we have to list the glapi object files? Is -Wl,--whole-archive enough? I think something like ABI breakage for Linux/X11 should also be added to the description of --disable-glx. libGL.so is required to have both GL and GLX entries on Linux/X11. Incidentally, there is an implementers guide on Khronos website that you might find interesting http://www.khronos.org/registry/implementers_guide.pdf I've also been thinking how to design the configure options such that it is possible to produce libraries for the target platform (libGL with or without GLX, or maybe OpenGL ES DRI drivers) for normal users. Addtionally, it should also be possible to enable everything so that any build failure can be catched. We might be able to start with smaller steps. The other patch renames glx to gl, now that it's no longer glx only, and moves the code up one level from src/glx/x11 to src/gl. The patch drops src/glx/mini; it's DRI1 only, not maintained and EGL on KMS is a better solution for the use cases where miniglx was useful. I haven't tried this. But ideally, I think src/glx/x11/ can be moved up one level to src/glx/. This directory will not be visited when --disable-glx. But when visited, it will build libglx.a from the sources. We can then build libGL.so with or without libglx.a depending on the configure optins. Later, src/mesa/drivers/x11/ could be changed to build libglxsw.a. We will be able to choose between 3 flavors of libGL.so, or choose all of them (to catch build failure) -- o...@lunarg.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] call for testers: galllium-screen-context branch
On 02/05/2010 11:01 AM, Keith Whitwell wrote:
We've had a couple of cleanups that we've wanted to do in gallium for
as long as I can remember. One of which is to remove all the random
context-creation calls and funnel them through something sensible like
a context_create() call in pipe_screen.
The gallium-screen-context branch does exactly that.
The trouble is this change touches every driver and state-tracker in
every combination. I can't even build half the drivers (what do I
need to install to build nouveau?), let alone test them in any
meaningful way.
Hi.
For building nouveau you'll need libdrm_nouveau.
Here's a patch that makes nv30,40,50 compile again; nv50 seems to work,
can't test the others.
Christoph
So, I really need people to take a look at this branch and make sure
you can still at least build the driver, run some simple apps, etc.
Keith
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
From 4aea3df06bb7d366bea76b7173c19419f0d20630 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Sat, 6 Feb 2010 17:03:43 +0100
Subject: [PATCH] nouveau: fix gallium-screen-context branch fallout
---
src/gallium/drivers/nouveau/nouveau_winsys.h |9
src/gallium/drivers/nv30/nv30_context.c |1 +
src/gallium/drivers/nv30/nv30_context.h |1 +
src/gallium/drivers/nv30/nv30_screen.c |1 -
src/gallium/drivers/nv30/nv30_screen.h |5 +--
src/gallium/drivers/nv30/nv30_transfer.c | 21 +-
src/gallium/drivers/nv40/nv40_context.c |1 +
src/gallium/drivers/nv40/nv40_context.h |3 +-
src/gallium/drivers/nv40/nv40_screen.c |1 -
src/gallium/drivers/nv40/nv40_screen.h |5 +--
src/gallium/drivers/nv40/nv40_transfer.c | 20 +
src/gallium/drivers/nv50/nv50_context.c |1 +
src/gallium/drivers/nv50/nv50_context.h |3 +-
src/gallium/drivers/nv50/nv50_screen.c |1 -
src/gallium/drivers/nv50/nv50_screen.h |2 -
src/gallium/drivers/nv50/nv50_transfer.c | 29 +
16 files changed, 49 insertions(+), 55 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_winsys.h
b/src/gallium/drivers/nouveau/nouveau_winsys.h
index 4c5d2f8..af9ddd5 100644
--- a/src/gallium/drivers/nouveau/nouveau_winsys.h
+++ b/src/gallium/drivers/nouveau/nouveau_winsys.h
@@ -29,19 +29,10 @@
extern struct pipe_screen *
nv30_screen_create(struct pipe_winsys *ws, struct nouveau_device *);
-extern struct pipe_context *
-nv30_create(struct pipe_screen *, unsigned pctx_id);
-
extern struct pipe_screen *
nv40_screen_create(struct pipe_winsys *ws, struct nouveau_device *);
-extern struct pipe_context *
-nv40_create(struct pipe_screen *, unsigned pctx_id);
-
extern struct pipe_screen *
nv50_screen_create(struct pipe_winsys *ws, struct nouveau_device *);
-extern struct pipe_context *
-nv50_create(struct pipe_screen *, unsigned pctx_id);
-
#endif
diff --git a/src/gallium/drivers/nv30/nv30_context.c
b/src/gallium/drivers/nv30/nv30_context.c
index 8bfd7b2..12932c1 100644
--- a/src/gallium/drivers/nv30/nv30_context.c
+++ b/src/gallium/drivers/nv30/nv30_context.c
@@ -75,6 +75,7 @@ nv30_create(struct pipe_screen *pscreen, void *priv)
nv30_init_query_functions(nv30);
nv30_init_surface_functions(nv30);
nv30_init_state_functions(nv30);
+ nv30_init_transfer_functions(nv30);
/* Create, configure, and install fallback swtnl path */
nv30-draw = draw_create();
diff --git a/src/gallium/drivers/nv30/nv30_context.h
b/src/gallium/drivers/nv30/nv30_context.h
index b3b26f7..419d9a5 100644
--- a/src/gallium/drivers/nv30/nv30_context.h
+++ b/src/gallium/drivers/nv30/nv30_context.h
@@ -161,6 +161,7 @@ struct nv30_state_entry {
extern void nv30_init_state_functions(struct nv30_context *nv30);
extern void nv30_init_surface_functions(struct nv30_context *nv30);
extern void nv30_init_query_functions(struct nv30_context *nv30);
+extern void nv30_init_transfer_functions(struct nv30_context *nv30);
extern void nv30_screen_init_miptree_functions(struct pipe_screen *pscreen);
diff --git a/src/gallium/drivers/nv30/nv30_screen.c
b/src/gallium/drivers/nv30/nv30_screen.c
index 8f9b26e..66ff17c 100644
--- a/src/gallium/drivers/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nv30/nv30_screen.c
@@ -212,7 +212,6 @@ nv30_screen_create(struct pipe_winsys *ws,
Re: [Mesa3d-dev] call for testers: galllium-screen-context branch
On 02/06/2010 05:05 PM, Christoph Bumiller wrote: On 02/05/2010 11:01 AM, Keith Whitwell wrote: We've had a couple of cleanups that we've wanted to do in gallium for as long as I can remember. One of which is to remove all the random context-creation calls and funnel them through something sensible like a context_create() call in pipe_screen. The gallium-screen-context branch does exactly that. The trouble is this change touches every driver and state-tracker in every combination. I can't even build half the drivers (what do I need to install to build nouveau?), let alone test them in any meaningful way. Hi. For building nouveau you'll need libdrm_nouveau. Here's a patch that makes nv30,40,50 compile again; nv50 seems to work, can't test the others. Oops, sorry, that was against gallium-context-transfers already, so only part of it applies to screen-context. I can also fix stuff once the branch(es) have been merged as well. Christoph So, I really need people to take a look at this branch and make sure you can still at least build the driver, run some simple apps, etc. Keith -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] empty vertex buffers
It's not deeply, truly painful, but it's certainly annoying and it would be nice to force buffers to be at least contiguously bound, if not non-sparse. I know D3D permits sparse elements though, so I won't hold my breath. On Sat, Feb 6, 2010 at 3:04 AM, Keith Whitwell keith.whitw...@googlemail.com wrote: On Fri, Feb 5, 2010 at 2:46 PM, Joakim Sindholt b...@zhasha.com wrote: Let's assume I have an array of vertex elements that indicate position/color in vertex buffer #3. Let's also for the sake of argument say that there is nothing else in my vertex elements. No other buffers are being pointed to. Is it legal for me to pipe_context::set_vertex_buffers with an array size of 3 and set buffer 1 and 2 == NULL? Not to mention buffer 0... At the moment I'd say that, yes this is permitted. I'm not sure if there is any state-tracker out there that really wants to be able to do this, though, so it is something we could look at tightening up if it is causing real pain at the driver level. Keith -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
On Sun, Jan 31, 2010 at 1:37 AM, Roland Scheidegger srol...@vmware.comwrote: 7) Is there more information on the dual-source blend modes? I'm not sure if I can do them; might have to bug AMD for the register values. I bet R300 can't do these modes. It's only a Direct3D 10.0 feature, not present in Direct3D 10.1. MS must have a good reason to remove it. Where did you see that it's removed in 10.1? Here's a list of blend ops in d3d11: http://msdn.microsoft.com/en-us/library/ee416042(VS.85).aspxhttp://msdn.microsoft.com/en-us/library/ee416042%28VS.85%29.aspx Note this feature can be present (via cap bits in some limited form) in D3D9Ex too, and I thought windows actually used it for (antialiased) text rendering (but don't quote me on that). You're right. My source was incorrect (OpenGL.org forums). -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
