[Mesa-dev] [PATCH] st/mesa: Check after _mesa_create_context()
In some cases _mesa_create_context() can return NULL
an in the mesa state tracker, we do not concider the
case, which may cause issues within st_create_context_priv()
This patch adds a simple check (similar to the one in the
dri drivers)
v2 Do not zero-out the funcs table
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/mesa/state_tracker/st_context.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_context.c
b/src/mesa/state_tracker/st_context.c
index 6eddbfc..6d4bc54 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -179,6 +179,9 @@ struct st_context *st_create_context(gl_api api, struct
pipe_context *pipe,
st_init_driver_functions(funcs);
ctx = _mesa_create_context(api, visual, shareCtx, funcs, NULL);
+ if (!ctx) {
+ return NULL;
+ }
/* XXX: need a capability bit in gallium to query if the pipe
* driver prefers DP4 or MUL/MAD for vertex transformation.
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Merging glsl-to-tgsi to master
Hello guys. 1 month ago, we talked about merging glsl-to-tgsi to master but it still not happend. What about now? I could compile and test it a bit. It works. Anyone who could do it? What does Bryan Cain say about it? Greetings ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Patch: Fix building mesa with llvm 3.0
Hi, I could not compile mesa with llvm 3.0 from svn. So i made this patch which fixes the issue: http://pastebin.com/1Y19vrFf Is this a proper patch? Or should there be more version checking with #if for it? Thank You ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Patch: Fix building mesa with llvm 3.0
Please try compiling again with mesa master commit e4189f2e2e310276136dc06af20062986920e8e2 or later. The build succeeds here with llvm-3.0svn but there's a missing LLVMAddTypeName symbol during runtime. From: mesa-dev-bounces+vlee=vmware@lists.freedesktop.org [mesa-dev-bounces+vlee=vmware@lists.freedesktop.org] On Behalf Of Carl-Philip Haensch [carl-philip.haen...@mailbox.tu-dresden.de] Sent: Monday, July 11, 2011 10:31 AM To: Jose Fonseca Cc: mesa-dev@lists.freedesktop.org Subject: [Mesa-dev] Patch: Fix building mesa with llvm 3.0 Hi, I could not compile mesa with llvm 3.0 from svn. So i made this patch which fixes the issue: http://pastebin.com/1Y19vrFf Is this a proper patch? Or should there be more version checking with #if for it? Thank You ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About merging pipe-video to master
On Mon, 2011-07-11 at 18:24 +0200, Christian König wrote: Hi guys, as the subject already indicates: I'm about to merge pipe-video to master and just wanted to ask if anybody has still any objections? After following Jose and Younes discussion on mesa-dev about how to design such an abstraction layer I took another round of cleaning up the interface and moved some more parts into the state tracker. So the interface between the state tracker and drivers only consist of the following now: 1. two additional functions for the screen object: get_video_param and is_video_format_supported. get_video_param gets a parameter for a specified codec (like max width/height of decoding target, which could be smaller than texture max width/height), and is_video_format_supported which checks if a texture format is supported as a decoding target for a codec. 2. create_video_decoder function in the pipe_context object, which creates a decoder object for a given codec. The decoder object in turn includes everything needed to decode a video stream of that codec and uses pipe_video_decode_buffer objects to hold the input data of a single frame of that video codec. 3. create_video_buffer function in the pipe_context object, which creates a video_buffer object to store a decoded video frame. This video_buffer object is then used for both rendering to the screen with normal pipe_context functionality and also as the input for reference frames back to the decoder. The pipe_video_buffer object is there because I think hardware decoders need some special memory layout of the different planes of a yuv buffer. There is a standard implementation that just uses normal textures as the different planes for yuv buffer, which can be used by a driver when there is no need for a special memory layout or when the driver just uses shader based decoding. The other option would be adding a PIPE_BIND_VIDEO_BUFFER flag to the resource creation functions, but I don't want to repeat functionality in the different drivers and as far as I can see the current resource functions (samplers/surfaces) can't be used to create a surface for just one plane/component of a yuv buffer and we could still clean that up to use the standard resource functions if the need arise. I'm a bit unsure about what's the best approach here, though at this stage I'm happy with your approach and don't think it needs to be changed before any merge. But speaking in general terms, individual planes map well onto 8-bit single-component texture images (L8 or similar) and any hardware requirements (pitch, memory pool, etc) for the individual plane could be specified with a PIPE_BIND_VIDEO_BUFFER flag. However, it's also easy to imagine hardware having special requirements about the positioning of the planes relative to one another, similar to how mipmaps must be layed out in hardware-specific ways. If we did decide to get rid of video_buffers and integrate the concept with pipe_resources, it seems like there would need to be a way to specify this at resource creation - either a planar YUV format, or some other marking on the resource. I don't have easy answers for that, and in the meantime I don't think it's important enough to hold up pipe-video, which is looking now like a good step forward. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About merging pipe-video to master
Hi, as the subject already indicates: I'm about to merge pipe-video to master and just wanted to ask if anybody has still any objections? Yes [I am a watchman of compile/build errors (I know I am an old bitcher but code quality rules)]: https://build.opensuse.org/package/rawlog?arch=x86_64package=Mesaproject=home%3Ajobermayr%3Atestrepository=openSUSE_11.4 Please merge things only when all new introduced things/switches compile/build successfully. I've fixed up the vaapi code so that it at least build correctly again. I don't really know what to do with this state tracker, one the one hand I don't want to support another video api (VDPAU seems pretty well designed to come by with everything you need), on the other hand it implements at least a skeleton api (to complete the state tracker somebody will just need to step up and implement everything in between the api and the driver), so I don't want to remove it either. Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About merging pipe-video to master
Am Dienstag, den 12.07.2011, 13:06 +0200 schrieb Henri Verbeet: 2011/7/11 Christian König deathsim...@vodafone.de: So what do you guys think about it? I didn't look much at the rest of the changes, but some of the changes for r600g (diff attached) look a bit questionable. Could you take a look at those to see if they're really all intentional and correct before merging? Already discussed those changes a bit with Alex, and double checked that it works with my available hardware (no piglit regressions). The changes to the winsys code is about making a bo optional, even when the reg informations says it isn't. This is useful for registers where only a subset of the bits needs to be informed about a bo relocation, and seems to work pretty fine as long as you don't touch those bits. On top of that it implements clamp_fragment_color also for the blender state, this is necessary because the blender will otherwise clamp the colour to [0,1] for unsigned and [-1,1] for signed buffers. This is another piece needed to get arb_color_buffer_float working correctly (without the need to recompile the shaders each time). Should I make a separate patch of this or is it ok to just merge it with the branch? Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] robust-tarballs branch (Was: Error building on Windows with SCons)
Hi Jose, On Sat, Jul 9, 2011 at 6:03 AM, Jose Fonseca jfons...@vmware.com wrote: I heard no concerns so I went ahead and made a branch where: - I removed GLUT - derived Mesa tarballs' file list from git ls-files. http://cgit.freedesktop.org/mesa/mesa/log/?h=robust-tarballs I've confirmed that both automake and scons+crossmingw32 build correctly on Linux. I'd like to merge to main if there are no objections. Having a brief look through the commits, it looks like a lot of nice cleanup. A couple comments. 26edecac589819f0d0efe2165ab748dbc4e53394: Using the variable DIRECTORY is a little confusing since it's a symlink. DIRLINK may be better. 34983337f9d7db984e9f0117808274106d262110: - src/mesa/depend is in EXTRA_FILES. This seems like something that shouldn't be shipped. - You're passing -x autogen.sh to not ship autogen.sh, but is that the only thing that shouldn't be disted? Any chance you could compare an old tarball to a new tarball and see if any unintended new files slipped in? - This might be for another commit, but it would be nice to move that to a separate variable. To start it could be hacky with the arguments embedded: IGNORE_FILES = \ -x autogen.sh \ -x otherunwantedfile - $(LIBNAME).zip should depend on manifest.txt Looks good otherwise, though. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] configure.ac: don't build gallium driver libs just to see if there are no errors
I think the past are those times when the gallium interface was changed all
the time. Now it is not, so there is no reason to always compile the libs
if they are not needed.
No idea why some hardware drivers need to contain whole softpipe and llvmpipe.
---
configure.ac | 23 +--
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index b65ffdf..ec1f170 100644
--- a/configure.ac
+++ b/configure.ac
@@ -750,7 +750,7 @@ GLU_DIRS=sgi
GALLIUM_DIRS=auxiliary drivers state_trackers
GALLIUM_TARGET_DIRS=
GALLIUM_WINSYS_DIRS=sw
-GALLIUM_DRIVERS_DIRS=softpipe failover galahad trace rbug noop identity
+GALLIUM_DRIVERS_DIRS=failover galahad trace rbug noop identity
GALLIUM_STATE_TRACKERS_DIRS=
# build shared-glapi if enabled for OpenGL or if OpenGL ES is enabled
@@ -1817,7 +1817,6 @@ if test x$enable_gallium_llvm = xyes; then
LLVM_LIBS=`$LLVM_CONFIG --libs` -lstdc++
LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
- GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS llvmpipe
DEFINES=$DEFINES -D__STDC_CONSTANT_MACROS
MESA_LLVM=1
else
@@ -1858,25 +1857,33 @@ gallium_require_llvm() {
}
dnl Gallium drivers
+dnl Duplicates in GALLIUM_DRIVERS_DIRS are removed by sorting it after this
block
if test x$with_gallium_drivers != x; then
-# This is for compile-testing
-GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS i915 i965 r300 svga
-GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS i915/sw
-
gallium_drivers=`IFS=', '; echo $with_gallium_drivers`
for driver in $gallium_drivers; do
case x$driver in
xsvga)
+GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS svga softpipe
gallium_check_st svga/drm dri-vmwgfx xorg-vmwgfx xa-vmwgfx
;;
xi915)
+GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS i915 softpipe
+if test x$MESA_LLVM = x1; then
+GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS llvmpipe
+fi
+GALLIUM_WINSYS_DIRS=$GALLIUM_WINSYS_DIRS i915/sw
gallium_check_st i915/drm dri-i915 xorg-i915
;;
xi965)
+GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS i965 softpipe
+if test x$MESA_LLVM = x1; then
+GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS llvmpipe
+fi
gallium_check_st i965/drm dri-i965 xorg-i965
;;
xr300)
gallium_require_llvm Gallium R300
+GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS r300
gallium_check_st radeon/drm dri-r300 xorg-r300
;;
xr600)
@@ -1889,6 +1896,10 @@ if test x$with_gallium_drivers != x; then
;;
xswrast)
if test x$HAVE_ST_DRI = xyes; then
+GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS softpipe
+if test x$MESA_LLVM = x1; then
+GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS llvmpipe
+fi
GALLIUM_TARGET_DIRS=$GALLIUM_TARGET_DIRS dri-swrast
fi
;;
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About merging pipe-video to master
2011/7/12 Christian König deathsim...@vodafone.de:
it works with my available hardware (no piglit regressions). The changes
to the winsys code is about making a bo optional, even when the reg
informations says it isn't. This is useful for registers where only a
subset of the bits needs to be informed about a bo relocation, and seems
to work pretty fine as long as you don't touch those bits.
Well, ok, but I'd expect to find that information in the commit log.
As it is, 68cc6bc5d8b6986acc7f5780d705f4ae9be2a446 removes
REG_FLAG_NEED_BO, then e602ecf9ef2f66289bcb159fdbdce2c76e3c07c1 adds
it back without much of an explanation. Also, what subset is that?
After this patch both places that touch the register pass NULL for the
bo.
+ // TODO get BLEND_CLAMP state from rasterizer state
Is this comment still accurate?
+ color_info, ~S_0280A0_BLEND_CLAMP(1), NULL);
Did you mean to write ~C_0280A0_BLEND_CLAMP there?
On top of that it implements clamp_fragment_color also for the blender
state, this is necessary because the blender will otherwise clamp the
colour to [0,1] for unsigned and [-1,1] for signed buffers.
This is another piece needed to get arb_color_buffer_float working
correctly (without the need to recompile the shaders each time).
You should probably remove the existing code that does that in
r600_shader_from_tgsi() then, at least for r600. Either way, it sounds
like this is a mostly independent change from the rest of pipe-video
and should go to r600g through the regular way, probably through the
mailing list first.
+switch (res-usage) {
+case PIPE_USAGE_STREAM:
+case PIPE_USAGE_STAGING:
+case PIPE_USAGE_STATIC:
+case PIPE_USAGE_IMMUTABLE:
+return FALSE;
+
+default:
+return TRUE;
+}
At the very least this has whitespace errors. Why do we want this?
Like the other change, the commit log for this change
(77217af40d67612d1f1089ca188393d27a8a038f) isn't very descriptive. If
it wasn't for the commit not being a merge commit, it would even be
ambiguous if Merge fix means merging a fix or fixing a merge.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] Rename swrastg_dri to swrast_dri
I'm in favor for this FWIW.
Jose
- Original Message -
I prefer it this way and it has been suggested earlier by others too.
Opinions?
---
src/egl/drivers/dri2/egl_dri2.c |5 -
src/gallium/targets/dri-swrast/Makefile |2 +-
src/gallium/targets/dri-swrast/SConscript |6 +++---
src/glx/drisw_glx.c |3 ---
4 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c
b/src/egl/drivers/dri2/egl_dri2.c
index 35a598e..0aca929 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -416,11 +416,6 @@ dri2_load_driver_swrast(_EGLDisplay *disp)
dri2_dpy-driver_name = swrast;
extensions = dri2_open_driver(disp);
- if (!extensions) {
- /* try again with swrastg */
- dri2_dpy-driver_name = swrastg;
- extensions = dri2_open_driver(disp);
- }
if (!extensions)
return EGL_FALSE;
diff --git a/src/gallium/targets/dri-swrast/Makefile
b/src/gallium/targets/dri-swrast/Makefile
index 948c45a..45b933e 100644
--- a/src/gallium/targets/dri-swrast/Makefile
+++ b/src/gallium/targets/dri-swrast/Makefile
@@ -1,7 +1,7 @@
TOP = ../../../..
include $(TOP)/configs/current
-LIBNAME = swrastg_dri.so
+LIBNAME = swrast_dri.so
DRIVER_DEFINES = \
-D__NOT_HAVE_DRM_H -DGALLIUM_SOFTPIPE \
diff --git a/src/gallium/targets/dri-swrast/SConscript
b/src/gallium/targets/dri-swrast/SConscript
index 33acc61..6b64c56 100644
--- a/src/gallium/targets/dri-swrast/SConscript
+++ b/src/gallium/targets/dri-swrast/SConscript
@@ -29,13 +29,13 @@ if env['llvm']:
env.Append(CPPDEFINES = 'GALLIUM_LLVMPIPE')
env.Prepend(LIBS = [llvmpipe])
-swrastg_sources = [
+swrast_sources = [
'swrast_drm_api.c'
]
module = env.LoadableModule(
-target ='swrastg_dri.so',
-source = swrastg_sources,
+target ='swrast_dri.so',
+source = swrast_sources,
SHLIBPREFIX = '',
)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index d63f6e8..d0137ee 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -425,9 +425,6 @@ driOpenSwrast(void)
if (driver == NULL)
driver = driOpenDriver(swrast);
- if (driver == NULL)
- driver = driOpenDriver(swrastg);
-
return driver;
}
--
1.7.4.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is it a memory leak?
On 07/12/2011 06:38 AM, Zhenbo Xu wrote:
Hi all,
I have been detecting memory leaks in mesa for SPEC2000,
and I found a kind of memory leaks shown in the following code
gl_text_image* image_to_texture(...) {
...
textImage = gl_alloc_texttrue_image(...);
if (!textImage)
return NULL;
...
switch (image-Type) {
case ...
...
default:
gl_problem(...)
return NULL; //here without releasing textImage
}
}
Is it a memory leak ?
Possibly. Where is this code exactly?
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] Rename swrastg_dri to swrast_dri
On 07/12/2011 07:27 AM, Marek Olšák wrote: I prefer it this way and it has been suggested earlier by others too. Opinions? OK by me. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: Check after _mesa_create_context()
On 07/11/2011 08:42 AM, Emil Velikov wrote:
In some cases _mesa_create_context() can return NULL
an in the mesa state tracker, we do not concider the
case, which may cause issues within st_create_context_priv()
This patch adds a simple check (similar to the one in the
dri drivers)
v2 Do not zero-out the funcs table
Signed-off-by: Emil Velikovemil.l.veli...@gmail.com
---
src/mesa/state_tracker/st_context.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_context.c
b/src/mesa/state_tracker/st_context.c
index 6eddbfc..6d4bc54 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -179,6 +179,9 @@ struct st_context *st_create_context(gl_api api, struct
pipe_context *pipe,
st_init_driver_functions(funcs);
ctx = _mesa_create_context(api, visual, shareCtx,funcs, NULL);
+ if (!ctx) {
+ return NULL;
+ }
/* XXX: need a capability bit in gallium to query if the pipe
* driver prefers DP4 or MUL/MAD for vertex transformation.
Pushed. Thanks.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is it a memory leak?
On 07/12/2011 08:40 AM, Zhenbo Xu wrote:
I found the following bugs in mesa(v100) for SPEC CPU2000 v1.3
leak bug 1:
//in file textimage.c at line 345
gl_text_image* image_to_texture(...) {
...
textImage = gl_alloc_texttrue_image(...);
if (!textImage)
return NULL;
...
switch (image-Type) {
case ...
...
default:
gl_problem(...)
return NULL; //here without releasing textImage
}
}
leak bug 2:
//in file osmesa.c at line 263
osmesa = (OSMesaContext) calloc( 1, sizeof(struct osmesa_context) );
262 if (osmesa) {
osmesa-gl_visual = gl_create_visual( rgbmode, 264 swalpha,
DEPTH_BITS16,
STENCIL_BITS8,
ACCUM_BITS16,
index_bits,
rscale, gscale, bscale, ascale,
8, 8, 8, 0 );
if (!osmesa-gl_visual) {
return NULL((void*)0);//without releasing osmesa
}
leak bug 3:
//in file drawpix.c at line 1010
void gl_DrawPixels(...) {
...
if (ctx-CallDepth == 0) {
image = gl_unpack_pixels( ctx, width, height, format, type, pixels );
...
}
...
if (ctx-ExecuteFlag) { //Taking false branch
gl_save_DrawPixels( ctx, width, height, format, type, image );
}
if (ctx-ExecuteFlag) { //Taking false branch
}//Without releasing image
}
Is it suitable to report these bugs here?
The Mesa code you're referring to is very old (circa 1999, I think).
Taking a quick look, I don't think these leaks currently exist in Mesa
today.
I also sent it to support@spec2000, but didn't have any response.
I'll be glad if you can check these bugs,
Or do I have another way to report them?
Thank you!
I doubt that the SPEC organization is concerned with bugs in spec2000
anymore either since it was retired in 2007.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is it a memory leak?
Thank you for your replies!
在 2011年7月12日 下午10:47，Brian Paul bri...@vmware.com写道：
On 07/12/2011 08:40 AM, Zhenbo Xu wrote:
I found the following bugs in mesa(v100) for SPEC CPU2000 v1.3
leak bug 1:
//in file textimage.c at line 345
gl_text_image* image_to_texture(...) {
...
textImage = gl_alloc_texttrue_image(...);
if (!textImage)
return NULL;
...
switch (image-Type) {
case ...
...
default:
gl_problem(...)
return NULL; //here without releasing textImage
}
}
leak bug 2:
//in file osmesa.c at line 263
osmesa = (OSMesaContext) calloc( 1, sizeof(struct osmesa_context) );
262 if (osmesa) {
osmesa-gl_visual = gl_create_visual( rgbmode, 264 swalpha,
DEPTH_BITS16,
STENCIL_BITS8,
ACCUM_BITS16,
index_bits,
rscale, gscale, bscale, ascale,
8, 8, 8, 0 );
if (!osmesa-gl_visual) {
return NULL((void*)0);//without releasing osmesa
}
leak bug 3:
//in file drawpix.c at line 1010
void gl_DrawPixels(...) {
...
if (ctx-CallDepth == 0) {
image = gl_unpack_pixels( ctx, width, height, format, type, pixels );
...
}
...
if (ctx-ExecuteFlag) { //Taking false branch
gl_save_DrawPixels( ctx, width, height, format, type, image );
}
if (ctx-ExecuteFlag) { //Taking false branch
}//Without releasing image
}
Is it suitable to report these bugs here?
The Mesa code you're referring to is very old (circa 1999, I think).
Taking a quick look, I don't think these leaks currently exist in Mesa
today.
I also sent it to support@spec2000, but didn't have any response.
I'll be glad if you can check these bugs,
Or do I have another way to report them?
Thank you!
I doubt that the SPEC organization is concerned with bugs in spec2000
anymore either since it was retired in 2007.
-Brian
--
Zhenbo Xu
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39147] egl_gallium.so: errors when linking
https://bugs.freedesktop.org/show_bug.cgi?id=39147 --- Comment #1 from Chia-I Wu olva...@gmail.com 2011-07-12 08:00:34 PDT --- Created an attachment (id=49010) View: https://bugs.freedesktop.org/attachment.cgi?id=49010 Review: https://bugs.freedesktop.org/review?bug=39147attachment=49010 fix linking errors Does this patch help? There are two hunks in the patch. If the patch helps, could you undo the second hunk and see if it is also needed? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About merging pipe-video to master
2011/7/12 Keith Whitwell kei...@vmware.com: I'm a bit unsure about what's the best approach here, though at this stage I'm happy with your approach and don't think it needs to be changed before any merge. But speaking in general terms, individual planes map well onto 8-bit single-component texture images (L8 or similar) and any hardware requirements (pitch, memory pool, etc) for the individual plane could be specified with a PIPE_BIND_VIDEO_BUFFER flag. However, it's also easy to imagine hardware having special requirements about the positioning of the planes relative to one another, similar to how mipmaps must be layed out in hardware-specific ways. If we did decide to get rid of video_buffers and integrate the concept with pipe_resources, it seems like there would need to be a way to specify this at resource creation - either a planar YUV format, or some other marking on the resource. I don't have easy answers for that, and in the meantime I don't think it's important enough to hold up pipe-video, which is looking now like a good step forward. Keith I've considered that. The problem that brings up is what happens when you need to hand that planar surface over to the 3D context as a texture to be sampled from for color conversion. From the state tracker's POV you've just handed over a single texture with corresponding vertex attribs, texcoords, shaders, etc, but in reality your 3D engine will have to treat each plane as a separate texture. You could special-case planar textures and internally create extra state objs and fix up the shader, but the extra complexity buys you nothing except a nicer looking planar texture representation in the interface and is ugly in itself. Anyhow, Christian, your changes look alright to me. Again, I don't think this interface has to be perfect now to be acceptable. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39158] [bisected]piglit glx/glx-swap-event_async failed
https://bugs.freedesktop.org/show_bug.cgi?id=39158 Ian Romanick i...@freedesktop.org changed: What|Removed |Added Component|Drivers/DRI/i965|GLX AssignedTo|i...@freedesktop.org |mesa-dev@lists.freedesktop. ||org CC||i...@freedesktop.org --- Comment #1 from Ian Romanick i...@freedesktop.org 2011-07-12 08:20:36 PDT --- This is not a bug in the i965 driver. The commit affects the generic GLX code, and the bug affects i915 hardware as well. Was this Mesa update tested with the corresponding xserver update? Perhaps the swap event extension should be disabled when there's a Mesa / xserver version mismatch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About merging pipe-video to master
On Tue, 2011-07-12 at 11:13 -0400, Younes Manton wrote: 2011/7/12 Keith Whitwell kei...@vmware.com: I'm a bit unsure about what's the best approach here, though at this stage I'm happy with your approach and don't think it needs to be changed before any merge. But speaking in general terms, individual planes map well onto 8-bit single-component texture images (L8 or similar) and any hardware requirements (pitch, memory pool, etc) for the individual plane could be specified with a PIPE_BIND_VIDEO_BUFFER flag. However, it's also easy to imagine hardware having special requirements about the positioning of the planes relative to one another, similar to how mipmaps must be layed out in hardware-specific ways. If we did decide to get rid of video_buffers and integrate the concept with pipe_resources, it seems like there would need to be a way to specify this at resource creation - either a planar YUV format, or some other marking on the resource. I don't have easy answers for that, and in the meantime I don't think it's important enough to hold up pipe-video, which is looking now like a good step forward. Keith I've considered that. The problem that brings up is what happens when you need to hand that planar surface over to the 3D context as a texture to be sampled from for color conversion. From the state tracker's POV you've just handed over a single texture with corresponding vertex attribs, texcoords, shaders, etc, but in reality your 3D engine will have to treat each plane as a separate texture. You could special-case planar textures and internally create extra state objs and fix up the shader, but the extra complexity buys you nothing except a nicer looking planar texture representation in the interface and is ugly in itself. Anyhow, Christian, your changes look alright to me. Again, I don't think this interface has to be perfect now to be acceptable. Agreed. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About merging pipe-video to master
- Original Message - Hi guys, as the subject already indicates: I'm about to merge pipe-video to master and just wanted to ask if anybody has still any objections? After following Jose and Younes discussion on mesa-dev about how to design such an abstraction layer I took another round of cleaning up the interface and moved some more parts into the state tracker. So the interface between the state tracker and drivers only consist of the following now: 1. two additional functions for the screen object: get_video_param and is_video_format_supported. get_video_param gets a parameter for a specified codec (like max width/height of decoding target, which could be smaller than texture max width/height), and is_video_format_supported which checks if a texture format is supported as a decoding target for a codec. 2. create_video_decoder function in the pipe_context object, which creates a decoder object for a given codec. The decoder object in turn includes everything needed to decode a video stream of that codec and uses pipe_video_decode_buffer objects to hold the input data of a single frame of that video codec. 3. create_video_buffer function in the pipe_context object, which creates a video_buffer object to store a decoded video frame. This video_buffer object is then used for both rendering to the screen with normal pipe_context functionality and also as the input for reference frames back to the decoder. The pipe_video_buffer object is there because I think hardware decoders need some special memory layout of the different planes of a yuv buffer. There is a standard implementation that just uses normal textures as the different planes for yuv buffer, which can be used by a driver when there is no need for a special memory layout or when the driver just uses shader based decoding. The other option would be adding a PIPE_BIND_VIDEO_BUFFER flag to the resource creation functions, but I don't want to repeat functionality in the different drivers and as far as I can see the current resource functions (samplers/surfaces) can't be used to create a surface for just one plane/component of a yuv buffer and we could still clean that up to use the standard resource functions if the need arise. Everything else, especially the vl_compositor functionality, is now part of the state tracker instead of the driver. The interface was mostly designed keeping two things in mind: First it should abstract the functionality of hardware video decoding from the state tracker and second it should be possible to implement a wide variety of different video decoding apis with it. For the second part I checked that it's at least possible to do XvMC,VDPAU,VAAPI and DXVA with it. So what do you guys think about it? I didn't have time to look in detail so that, and I'm not sure if I'll have time tomorrow either, but it sounds good from your description, and we can always cleanup loose ends later, so I have no objection proceeding. One final request, please make sure that any new source files in src/gallium/drivers/ and src/gallium/auxiliary are listed in SConscript, to prevent breaking our automated builds. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] configure.ac: don't build gallium driver libs just to see if there are no errors
On Tue, Jul 12, 2011 at 4:28 PM, Brian Paul bri...@vmware.com wrote: On 07/12/2011 07:27 AM, Marek Olšák wrote: I think the past are those times when the gallium interface was changed all the time. Now it is not, so there is no reason to always compile the libs if they are not needed. No idea why some hardware drivers need to contain whole softpipe and llvmpipe. My only guess is that we were putting both drivers in one .so and using a var to switch between the hw driver and softpipe for quick debuging/comparisons. Can you try building/testing without that dependency and see what happens? Yeah. The softpipe and llvmpipe dependency can be removed by: 1) undefining GALLIUM_LLVMPIPE and GALLIUM_SOFTPIPE 2) removing the .a libs from Makefiles After that the GALLIUM_DRIVER variable is basically ignored. Doing step (2) without (1) causes a linker failure. I leave that change to maintainers of the respective drivers. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About merging pipe-video to master
Am Dienstag, den 12.07.2011, 15:44 +0200 schrieb Henri Verbeet:
2011/7/12 Christian König deathsim...@vodafone.de:
it works with my available hardware (no piglit regressions). The changes
to the winsys code is about making a bo optional, even when the reg
informations says it isn't. This is useful for registers where only a
subset of the bits needs to be informed about a bo relocation, and seems
to work pretty fine as long as you don't touch those bits.
Well, ok, but I'd expect to find that information in the commit log.
As it is, 68cc6bc5d8b6986acc7f5780d705f4ae9be2a446 removes
REG_FLAG_NEED_BO, then e602ecf9ef2f66289bcb159fdbdce2c76e3c07c1 adds
it back without much of an explanation. Also, what subset is that?
After this patch both places that touch the register pass NULL for the
bo.
Sounds like you're right. Adding the flag again was followed by a
discussion with Alex on the mailing list
(http://lists.freedesktop.org/archives/mesa-dev/2011-April/007069.html),
and I should have documented that a bit more. Also the second place
shouldn't pass NULL for the bo, that is indeed a bug.
+ // TODO get BLEND_CLAMP state from rasterizer state
Is this comment still accurate?
Yes it is, the very first generation of R600 chipsets need to know if
blend clamping is enabled, to enable an additionally optimisation for
the color export (EXPORT_NORM).
The problem is that I'm unsure how to get that state from the rasterizer
structure into r600_cb, reprogramming color_info in r600_draw_vbo just
like Vadim Girlin did for his patches, seems to be a bit to much
overhead to me.
+ color_info, ~S_0280A0_BLEND_CLAMP(1), NULL);
Did you mean to write ~C_0280A0_BLEND_CLAMP there?
Yes, it should write every bit except BLEND_CLAMP here.
On top of that it implements clamp_fragment_color also for the blender
state, this is necessary because the blender will otherwise clamp the
colour to [0,1] for unsigned and [-1,1] for signed buffers.
This is another piece needed to get arb_color_buffer_float working
correctly (without the need to recompile the shaders each time).
You should probably remove the existing code that does that in
r600_shader_from_tgsi() then, at least for r600.
It's a bit more complicated than this, BLEND_CLAMP can only be used for
normalized buffers, but not float buffers. So we still need the
workaround with the shader recompile for those.
Vadim Girlin patches are indeed quite right for float buffers, the
problem is that disabling fragment color clamping currently doesn't work
correctly under the following conditions (with the code in master
branch):
1) you got a unsigned normalized buffer
2) you use a blender with ADD or SUB operation
3) your fragment shader outputs negative values
It took me a week to figure out what's going wrong here and why the
pipeline doesn't did what I wanted. The downside with my patches is that
it disables the export optimisation on the early R600 generation
chipsets, but my overall feeling is that it's better to render right and
slow instead of fast and wrong.
Either way, it sounds
like this is a mostly independent change from the rest of pipe-video
and should go to r600g through the regular way, probably through the
mailing list first.
Akk, I will send these as separate patches then.
+switch (res-usage) {
+case PIPE_USAGE_STREAM:
+case PIPE_USAGE_STAGING:
+case PIPE_USAGE_STATIC:
+case PIPE_USAGE_IMMUTABLE:
+return FALSE;
+
+default:
+return TRUE;
+}
At the very least this has whitespace errors. Why do we want this?
Like the other change, the commit log for this change
(77217af40d67612d1f1089ca188393d27a8a038f) isn't very descriptive. If
it wasn't for the commit not being a merge commit, it would even be
ambiguous if Merge fix means merging a fix or fixing a merge.
It was fixing a merge, as it turned out Mathias Fröhlich and I were
working on the same thing - placing bo buffers in different domains
depending on the resource usage.
Additional to that, these lines (which were part of my patch, but not of
Mathias code) should ensure that the driver doesn't tries to copy things
with a hardware blit from the staging area to vram.
For PIPE_USAGE_STREAM it doesn't makes sense because the very first
thing done with it is copying the data to the right position inside
another (much larger) buffer anyway.
For PIPE_USAGE_STAGING it doesn't make sense because the resource is
already marked as a STAGING resource anyway.
PIPE_USAGE_STATIC resources shouldn't be accessed by the CPU anyway.
And at least my PIPE_USAGE_IMMUTABLE resources are small and change so
infrequently that setting up a hardware blit takes more time than
copying them with the CPU.
Sorry for the confusion about the history of those patches, but I've
used git reset --hard while merge to get ride of my patches (BIG
mistake I know that
[Mesa-dev] [Bug 39147] egl_gallium.so: errors when linking
https://bugs.freedesktop.org/show_bug.cgi?id=39147 --- Comment #2 from Laurent carlier lordhea...@gmail.com 2011-07-12 08:59:17 PDT --- The patch fixes the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39147] egl_gallium.so: errors when linking
https://bugs.freedesktop.org/show_bug.cgi?id=39147 --- Comment #3 from Laurent carlier lordhea...@gmail.com 2011-07-12 09:11:40 PDT --- ... and applying only the first hunk seems enough. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39158] [bisected]piglit glx/glx-swap-event_async failed
https://bugs.freedesktop.org/show_bug.cgi?id=39158 Ian Romanick i...@freedesktop.org changed: What|Removed |Added AssignedTo|mesa-dev@lists.freedesktop. |jbar...@virtuousgeek.org |org | --- Comment #2 from Ian Romanick i...@freedesktop.org 2011-07-12 09:53:02 PDT --- I *hate* the reset assignee to default box. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] Rename swrastg_dri to swrast_dri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/12/2011 06:27 AM, Marek Olšák wrote:
I prefer it this way and it has been suggested earlier by others too.
Opinions?
So what happens to people that don't build any of gallium but do
occasionally compare with a software driver? Does this make both
gallium and classic build swrast_dri.so? That seems weird.
---
src/egl/drivers/dri2/egl_dri2.c |5 -
src/gallium/targets/dri-swrast/Makefile |2 +-
src/gallium/targets/dri-swrast/SConscript |6 +++---
src/glx/drisw_glx.c |3 ---
4 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 35a598e..0aca929 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -416,11 +416,6 @@ dri2_load_driver_swrast(_EGLDisplay *disp)
dri2_dpy-driver_name = swrast;
extensions = dri2_open_driver(disp);
- if (!extensions) {
- /* try again with swrastg */
- dri2_dpy-driver_name = swrastg;
- extensions = dri2_open_driver(disp);
- }
if (!extensions)
return EGL_FALSE;
diff --git a/src/gallium/targets/dri-swrast/Makefile
b/src/gallium/targets/dri-swrast/Makefile
index 948c45a..45b933e 100644
--- a/src/gallium/targets/dri-swrast/Makefile
+++ b/src/gallium/targets/dri-swrast/Makefile
@@ -1,7 +1,7 @@
TOP = ../../../..
include $(TOP)/configs/current
-LIBNAME = swrastg_dri.so
+LIBNAME = swrast_dri.so
DRIVER_DEFINES = \
-D__NOT_HAVE_DRM_H -DGALLIUM_SOFTPIPE \
diff --git a/src/gallium/targets/dri-swrast/SConscript
b/src/gallium/targets/dri-swrast/SConscript
index 33acc61..6b64c56 100644
--- a/src/gallium/targets/dri-swrast/SConscript
+++ b/src/gallium/targets/dri-swrast/SConscript
@@ -29,13 +29,13 @@ if env['llvm']:
env.Append(CPPDEFINES = 'GALLIUM_LLVMPIPE')
env.Prepend(LIBS = [llvmpipe])
-swrastg_sources = [
+swrast_sources = [
'swrast_drm_api.c'
]
module = env.LoadableModule(
-target ='swrastg_dri.so',
-source = swrastg_sources,
+target ='swrast_dri.so',
+source = swrast_sources,
SHLIBPREFIX = '',
)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index d63f6e8..d0137ee 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -425,9 +425,6 @@ driOpenSwrast(void)
if (driver == NULL)
driver = driOpenDriver(swrast);
- if (driver == NULL)
- driver = driOpenDriver(swrastg);
-
return driver;
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4cfMEACgkQX1gOwKyEAw+5KwCdHanTb/bAJnYbrSZU1cNYryLH
EokAoItGM5ftUKRSKCENCo8el+B02eZ2
=b9Bt
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging glsl-to-tgsi to master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/11/2011 09:53 AM, Egon Ashrafinia wrote: Hello guys. 1 month ago, we talked about merging glsl-to-tgsi to master but it still not happend. What about now? I could compile and test it a bit. It works. Anyone who could do it? What does Bryan Cain say about it? One thing to consider is whether or not this will make it more difficult to cherry pick fixes to the 7.11 release branch. Bryan has been doing some really cool work, and I'd like to see it get merged. However, I also want 7.11 to ship on time and with as few bugs as possible. Anything that will make that more difficult should wait until August. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4cfcIACgkQX1gOwKyEAw9/+QCffZMyD45ChgwvAm5B2NJPE+G3 9aEAnA4eC8eipdDJ2vGJMVFRHfSg6X5v =zdUh -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] About merging pipe-video to master
2011/7/12 Christian König deathsim...@vodafone.de: Am Dienstag, den 12.07.2011, 15:44 +0200 schrieb Henri Verbeet: 2011/7/12 Christian König deathsim...@vodafone.de: + // TODO get BLEND_CLAMP state from rasterizer state Is this comment still accurate? Yes it is, the very first generation of R600 chipsets need to know if blend clamping is enabled, to enable an additionally optimisation for the color export (EXPORT_NORM). The problem is that I'm unsure how to get that state from the rasterizer structure into r600_cb, reprogramming color_info in r600_draw_vbo just like Vadim Girlin did for his patches, seems to be a bit to much overhead to me. I don't think you can in the current setup. You'd pretty much have to do something along the lines of r600_spi_update() or r600_update_alpha_ref(). It took me a week to figure out what's going wrong here and why the pipeline doesn't did what I wanted. The downside with my patches is that it disables the export optimisation on the early R600 generation chipsets, but my overall feeling is that it's better to render right and slow instead of fast and wrong. I guess my point was mostly that there's not much of a point in doing the clamping both through BLEND_CLAMP and the fragment shader. Also, I guess we need this for EG+ as well. Thanks for clearing this up. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] Rename swrastg_dri to swrast_dri
- Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 06:27 AM, Marek Olšák wrote: I prefer it this way and it has been suggested earlier by others too. Opinions? So what happens to people that don't build any of gallium but do occasionally compare with a software driver? Does this make both gallium and classic build swrast_dri.so? That seems weird. People that don't build any of gallium don't get affected by any of this. People that want to build both of them will need to point LIBGL_DRIVER_PATH to right one. Distro will only ship one. It's similar to DRI libGL.so vs XLIB libGL.so. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] Rename swrastg_dri to swrast_dri
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 10:04 AM, Jose Fonseca wrote: - Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2011 06:27 AM, Marek Olšák wrote: I prefer it this way and it has been suggested earlier by others too. Opinions? So what happens to people that don't build any of gallium but do occasionally compare with a software driver? Does this make both gallium and classic build swrast_dri.so? That seems weird. People that don't build any of gallium don't get affected by any of this. People that want to build both of them will need to point LIBGL_DRIVER_PATH to right one. Distro will only ship one. It's similar to DRI libGL.so vs XLIB libGL.so. Okay. Good enough for me. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4cf/QACgkQX1gOwKyEAw9uawCgjZxghWOCNYcJWsGVE7FfzaKi HUgAnRXTmoQ3NC++9xstP+RZNSASCdzW =8LH7 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging glsl-to-tgsi to master
I'd like to see it merged eventually for my GSoC student's work, which will probably depend on it, but waiting until August will probably be alright. ~ C. On Wed, Jul 13, 2011 at 1:00 AM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/11/2011 09:53 AM, Egon Ashrafinia wrote: Hello guys. 1 month ago, we talked about merging glsl-to-tgsi to master but it still not happend. What about now? I could compile and test it a bit. It works. Anyone who could do it? What does Bryan Cain say about it? One thing to consider is whether or not this will make it more difficult to cherry pick fixes to the 7.11 release branch. Bryan has been doing some really cool work, and I'd like to see it get merged. However, I also want 7.11 to ship on time and with as few bugs as possible. Anything that will make that more difficult should wait until August. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk4cfcIACgkQX1gOwKyEAw9/+QCffZMyD45ChgwvAm5B2NJPE+G3 9aEAnA4eC8eipdDJ2vGJMVFRHfSg6X5v =zdUh -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging glsl-to-tgsi to master
On Wed, 13 Jul 2011 01:18:16 +0800 Corbin Simpson mostawesomed...@gmail.com wrote: I'd like to see it merged eventually for my GSoC student's work, which will probably depend on it, but waiting until August will probably be alright. No, the post-processing doesn't depend on the glsl-to-tgsi work, at least as it is currently. - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging glsl-to-tgsi to master
On 07/11/2011 11:53 AM, Egon Ashrafinia wrote: Hello guys. 1 month ago, we talked about merging glsl-to-tgsi to master but it still not happend. What about now? I could compile and test it a bit. It works. Anyone who could do it? What does Bryan Cain say about it? Hi Egon, Last month, I was trying to get it merged before the 7.11 merge window closed. When that didn't happen, I decided to stop being in a hurry and instead make some more improvements before trying again to get it merged to master. Also, Brian Paul pointed out an issue that I hadn't noticed before where st/mesa needed the current fragment shader to be in Mesa IR form for glBitmap, glDrawPixels, and glCopyPixels to work correctly. All of that is done now, as I finished the glBitmap path on Sunday and the DrawPixels/CopyPixels path on Saturday. So now I need to fix a few minor things like commit messages and one case where the old path generates better code than glsl_to_tgsi. The merge might also be delayed a bit further if it's decided that it should wait until after 7.11 is released, as Ian's reply suggested. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Case where opt_copy_propagation doesn't do its job
It appears that the copy propagation pass in the GLSL compiler (in opt_copy_propagation.cpp) doesn't do copy propagation when the components of a variable are initialized separately, like this: (declare (temporary ) vec4 vec_ctor) (assign (w) (var_ref vec_ctor) (constant float (1.00)) ) (assign (xyz) (var_ref vec_ctor) (var_ref assignment_tmp@16) ) (assign (xyzw) (var_ref gl_FragColor) (var_ref vec_ctor) ) In the past, this wasn't visible in the Mesa IR output because Mesa IR optimization seems to do the copy propagation. However, glsl_to_tgsi doesn't do copy propagation to output registers - in fact, I believe this is the only case left where ir_to_mesa produces better code than glsl_to_tgsi. I'm not very enthusiastic about the idea adding to the copy propagation pass in glsl_to_tgsi, since this case is something that should really be optimized by the GLSL compiler before it reaches the IR backend. So, is there a reason why the GLSL copy propagation pass doesn't operate per-component? Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging glsl-to-tgsi to master
Am 12.07.2011 21:44, schrieb Bryan Cain: On 07/11/2011 11:53 AM, Egon Ashrafinia wrote: Hello guys. 1 month ago, we talked about merging glsl-to-tgsi to master but it still not happend. What about now? I could compile and test it a bit. It works. Anyone who could do it? What does Bryan Cain say about it? Hi Egon, Last month, I was trying to get it merged before the 7.11 merge window closed. When that didn't happen, I decided to stop being in a hurry and instead make some more improvements before trying again to get it merged to master. Also, Brian Paul pointed out an issue that I hadn't noticed before where st/mesa needed the current fragment shader to be in Mesa IR form for glBitmap, glDrawPixels, and glCopyPixels to work correctly. All of that is done now, as I finished the glBitmap path on Sunday and the DrawPixels/CopyPixels path on Saturday. So now I need to fix a few minor things like commit messages and one case where the old path generates better code than glsl_to_tgsi. The merge might also be delayed a bit further if it's decided that it should wait until after 7.11 is released, as Ian's reply suggested. Bryan Hello Bryan, thank you for your answere. I understand and agree with your points. I also think that this is the better way to handle. Keep up the good work and try to improve and fix things, until 7.11 is released. Best wishes Egon P.s. The first Phoronix Article, which is created because of me **. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Case where opt_copy_propagation doesn't do its job
On Tue, 12 Jul 2011 15:44:12 -0500, Bryan Cain bryanca...@gmail.com wrote: It appears that the copy propagation pass in the GLSL compiler (in opt_copy_propagation.cpp) doesn't do copy propagation when the components of a variable are initialized separately, like this: (declare (temporary ) vec4 vec_ctor) (assign (w) (var_ref vec_ctor) (constant float (1.00)) ) (assign (xyz) (var_ref vec_ctor) (var_ref assignment_tmp@16) ) (assign (xyzw) (var_ref gl_FragColor) (var_ref vec_ctor) ) In the past, this wasn't visible in the Mesa IR output because Mesa IR optimization seems to do the copy propagation. However, glsl_to_tgsi doesn't do copy propagation to output registers - in fact, I believe this is the only case left where ir_to_mesa produces better code than glsl_to_tgsi. I'm not very enthusiastic about the idea adding to the copy propagation pass in glsl_to_tgsi, since this case is something that should really be optimized by the GLSL compiler before it reaches the IR backend. So, is there a reason why the GLSL copy propagation pass doesn't operate per-component? opt_copy_propagation_elements does that, but it doesn't split up the assignment into multiple assignments (otherwise, imagine initializing vec_ctor once and using it many times -- how do you decide whether copy propagate or not, to avoid pessimizing the code?). I think the operation you're looking for isn't really copy propagation, but more like register coalescing where you see that vec_ctor doesn't get redefined and used after being assigned to gl_FragColor, and just store the two in the same place. And yes, I think it would be useful to have something like that. Either that or generate new ir_quadop_vector in copy propagation. pgpuiTNNZtrb7.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/12] intel: Move intel_draw_buffers() code into each driver.
The illusion of shared code here wasn't fooling anybody. It was
tempting to keep i830 and i915 still shared, but I think I actually
want to make them diverge shortly.
---
src/mesa/drivers/dri/i915/i830_vtbl.c | 202
src/mesa/drivers/dri/i915/i915_vtbl.c | 200 +++
src/mesa/drivers/dri/i965/brw_vtbl.c | 201 +++
src/mesa/drivers/dri/intel/intel_buffers.c | 199 ---
src/mesa/drivers/dri/intel/intel_buffers.h |9 +-
src/mesa/drivers/dri/intel/intel_context.h |1 +
6 files changed, 612 insertions(+), 200 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
b/src/mesa/drivers/dri/i915/i830_vtbl.c
index 7775e71..7dba135 100644
--- a/src/mesa/drivers/dri/i915/i830_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i830_vtbl.c
@@ -31,10 +31,13 @@
#include intel_regions.h
#include intel_tris.h
#include intel_fbo.h
+#include intel_buffers.h
#include tnl/tnl.h
#include tnl/t_context.h
#include tnl/t_vertex.h
#include swrast_setup/swrast_setup.h
+#include main/renderbuffer.h
+#include main/framebuffer.h
#define FILE_DEBUG_FLAG DEBUG_STATE
@@ -695,6 +698,204 @@ i830_set_draw_region(struct intel_context *intel,
I830_STATECHANGE(i830, I830_UPLOAD_BUFFERS);
}
+/**
+ * Update the hardware state for drawing into a window or framebuffer object.
+ *
+ * Called by glDrawBuffer, glBindFramebufferEXT, MakeCurrent, and other
+ * places within the driver.
+ *
+ * Basically, this needs to be called any time the current framebuffer
+ * changes, the renderbuffers change, or we need to draw into different
+ * color buffers.
+ */
+static void
+i830_update_draw_buffer(struct intel_context *intel)
+{
+ struct gl_context *ctx = intel-ctx;
+ struct gl_framebuffer *fb = ctx-DrawBuffer;
+ struct intel_region *colorRegions[MAX_DRAW_BUFFERS], *depthRegion = NULL;
+ struct intel_renderbuffer *irbDepth = NULL, *irbStencil = NULL;
+ bool fb_has_hiz = intel_framebuffer_has_hiz(fb);
+
+ if (!fb) {
+ /* this can happen during the initial context initialization */
+ return;
+ }
+
+ /*
+* If intel_context is using separate stencil, but the depth attachment
+* (gl_framebuffer.Attachment[BUFFER_DEPTH]) has a packed depth/stencil
+* format, then we must install the real depth buffer at fb-_DepthBuffer
+* and set fb-_DepthBuffer-Wrapped before calling
_mesa_update_framebuffer.
+* Otherwise, _mesa_update_framebuffer will create and install a swras
+* depth wrapper instead.
+*
+* Ditto for stencil.
+*/
+ irbDepth = intel_get_renderbuffer(fb, BUFFER_DEPTH);
+ if (irbDepth irbDepth-Base.Format == MESA_FORMAT_X8_Z24) {
+ _mesa_reference_renderbuffer(fb-_DepthBuffer, irbDepth-Base);
+ irbDepth-Base.Wrapped = fb-Attachment[BUFFER_DEPTH].Renderbuffer;
+ }
+
+ irbStencil = intel_get_renderbuffer(fb, BUFFER_STENCIL);
+ if (irbStencil irbStencil-Base.Format == MESA_FORMAT_S8) {
+ _mesa_reference_renderbuffer(fb-_StencilBuffer, irbStencil-Base);
+ irbStencil-Base.Wrapped = fb-Attachment[BUFFER_STENCIL].Renderbuffer;
+ }
+
+ /* Do this here, not core Mesa, since this function is called from
+* many places within the driver.
+*/
+ if (ctx-NewState _NEW_BUFFERS) {
+ /* this updates the DrawBuffer-_NumColorDrawBuffers fields, etc */
+ _mesa_update_framebuffer(ctx);
+ /* this updates the DrawBuffer's Width/Height if it's a FBO */
+ _mesa_update_draw_buffer_bounds(ctx);
+ }
+
+ if (fb-_Status != GL_FRAMEBUFFER_COMPLETE_EXT) {
+ /* this may occur when we're called by glBindFrameBuffer() during
+ * the process of someone setting up renderbuffers, etc.
+ */
+ /*_mesa_debug(ctx, DrawBuffer: incomplete user FBO\n);*/
+ return;
+ }
+
+ /* How many color buffers are we drawing into?
+*
+* If there are zero buffers or the buffer is too big, don't configure any
+* regions for hardware drawing. We'll fallback to software below. Not
+* having regions set makes some of the software fallback paths faster.
+*/
+ if ((fb-Width ctx-Const.MaxRenderbufferSize)
+ || (fb-Height ctx-Const.MaxRenderbufferSize)
+ || (fb-_NumColorDrawBuffers == 0)) {
+ /* writing to 0 */
+ colorRegions[0] = NULL;
+ }
+ else if (fb-_NumColorDrawBuffers 1) {
+ int i;
+ struct intel_renderbuffer *irb;
+
+ for (i = 0; i fb-_NumColorDrawBuffers; i++) {
+ irb = intel_renderbuffer(fb-_ColorDrawBuffers[i]);
+ colorRegions[i] = irb ? irb-region : NULL;
+ }
+ }
+ else {
+ /* Get the intel_renderbuffer for the single colorbuffer we're drawing
+ * into.
+ */
+ if (fb-Name == 0) {
+/* drawing to window system buffer */
+if (fb-_ColorDrawBufferIndexes[0] == BUFFER_FRONT_LEFT)
+ colorRegions[0] = intel_get_rb_region(fb, BUFFER_FRONT_LEFT);
+else
+
[Mesa-dev] [PATCH 01/12] intel: Use the post-execution batchbuffer contents for dumping.
We were missing out on all the relocation changes by dumping what we
subdata()ed in instead of what's there after the kernel finished with
it.
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index 7353829..b61a2ff 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -127,9 +127,11 @@ do_flush_locked(struct intel_context *intel)
}
if (unlikely(INTEL_DEBUG DEBUG_BATCH)) {
- intel_decode(batch-map, batch-used,
+ drm_intel_bo_map(batch-bo, false);
+ intel_decode(batch-bo-virtual, batch-used,
batch-bo-offset,
intel-intelScreen-deviceID, GL_TRUE);
+ drm_intel_bo_unmap(batch-bo);
if (intel-vtbl.debug_batch != NULL)
intel-vtbl.debug_batch(intel);
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/12] intel: Clarify the depthRb == stencilRb logic.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 31 +++
1 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 1669af2..55bcc75 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -783,22 +783,21 @@ intel_validate_framebuffer(struct gl_context *ctx, struct
gl_framebuffer *fb)
* The depth and stencil renderbuffers are the same renderbuffer or wrap
* the same texture.
*/
- bool depth_stencil_are_same;
- if (depthRb stencilRb depthRb == stencilRb)
- depth_stencil_are_same = true;
- else if (depthRb stencilRb depthRb != stencilRb
-(fb-Attachment[BUFFER_DEPTH].Type == GL_TEXTURE)
-(fb-Attachment[BUFFER_STENCIL].Type == GL_TEXTURE)
-(fb-Attachment[BUFFER_DEPTH].Texture-Name
- == fb-Attachment[BUFFER_STENCIL].Texture-Name))
- depth_stencil_are_same = true;
- else
- depth_stencil_are_same = false;
-
- if (!intel-has_separate_stencil
-depthRb stencilRb
-!depth_stencil_are_same) {
- fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED_EXT;
+ if (depthRb stencilRb) {
+ bool depth_stencil_are_same;
+ if (depthRb == stencilRb)
+depth_stencil_are_same = true;
+ else if ((fb-Attachment[BUFFER_DEPTH].Type == GL_TEXTURE)
+ (fb-Attachment[BUFFER_STENCIL].Type == GL_TEXTURE)
+ (fb-Attachment[BUFFER_DEPTH].Texture-Name ==
+ fb-Attachment[BUFFER_STENCIL].Texture-Name))
+depth_stencil_are_same = true;
+ else
+depth_stencil_are_same = false;
+
+ if (!intel-has_separate_stencil !depth_stencil_are_same) {
+fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED_EXT;
+ }
}
for (i = 0; i Elements(fb-Attachment); i++) {
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/12] i965: Remove empty brw_set_draw_region.
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 1609938..5f67239 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -230,8 +230,6 @@ brw_update_draw_buffer(struct intel_context *intel)
intel-NewGLState |= (_NEW_DEPTH | _NEW_STENCIL);
}
- intel-vtbl.set_draw_region(intel, colorRegions, depthRegion,
- fb-_NumColorDrawBuffers);
intel-NewGLState |= _NEW_BUFFERS;
/* update viewport since it depends on window size */
@@ -262,17 +260,6 @@ brw_update_draw_buffer(struct intel_context *intel)
}
/**
- * called from intelDrawBuffer()
- */
-static void brw_set_draw_region( struct intel_context *intel,
- struct intel_region *color_regions[],
- struct intel_region *depth_region,
- GLuint num_color_regions)
-{
-}
-
-
-/**
* called from intel_batchbuffer_flush and children before sending a
* batchbuffer off.
*/
@@ -347,7 +334,6 @@ void brwInitVtbl( struct brw_context *brw )
brw-intel.vtbl.finish_batch = brw_finish_batch;
brw-intel.vtbl.destroy = brw_destroy_context;
brw-intel.vtbl.update_draw_buffer = brw_update_draw_buffer;
- brw-intel.vtbl.set_draw_region = brw_set_draw_region;
brw-intel.vtbl.debug_batch = brw_debug_batch;
brw-intel.vtbl.render_target_supported = brw_render_target_supported;
brw-intel.vtbl.is_hiz_depth_format = brw_is_hiz_depth_format;
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/12] i965: Remove unused region calculations in brw_update_draw_buffer().
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 62 +
1 files changed, 2 insertions(+), 60 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 5f67239..831c3e0 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -94,7 +94,6 @@ brw_update_draw_buffer(struct intel_context *intel)
{
struct gl_context *ctx = intel-ctx;
struct gl_framebuffer *fb = ctx-DrawBuffer;
- struct intel_region *colorRegions[MAX_DRAW_BUFFERS], *depthRegion = NULL;
struct intel_renderbuffer *irbDepth = NULL, *irbStencil = NULL;
bool fb_has_hiz = intel_framebuffer_has_hiz(fb);
@@ -143,58 +142,9 @@ brw_update_draw_buffer(struct intel_context *intel)
return;
}
- /* How many color buffers are we drawing into?
-*
-* If there are zero buffers or the buffer is too big, don't configure any
-* regions for hardware drawing. We'll fallback to software below. Not
-* having regions set makes some of the software fallback paths faster.
+ /* Check some stencil invariants. These should probably be in
+* emit_depthbuffer().
*/
- if ((fb-Width ctx-Const.MaxRenderbufferSize)
- || (fb-Height ctx-Const.MaxRenderbufferSize)
- || (fb-_NumColorDrawBuffers == 0)) {
- /* writing to 0 */
- colorRegions[0] = NULL;
- }
- else if (fb-_NumColorDrawBuffers 1) {
- int i;
- struct intel_renderbuffer *irb;
-
- for (i = 0; i fb-_NumColorDrawBuffers; i++) {
- irb = intel_renderbuffer(fb-_ColorDrawBuffers[i]);
- colorRegions[i] = irb ? irb-region : NULL;
- }
- }
- else {
- /* Get the intel_renderbuffer for the single colorbuffer we're drawing
- * into.
- */
- if (fb-Name == 0) {
-/* drawing to window system buffer */
-if (fb-_ColorDrawBufferIndexes[0] == BUFFER_FRONT_LEFT)
- colorRegions[0] = intel_get_rb_region(fb, BUFFER_FRONT_LEFT);
-else
- colorRegions[0] = intel_get_rb_region(fb, BUFFER_BACK_LEFT);
- }
- else {
-/* drawing to user-created FBO */
-struct intel_renderbuffer *irb;
-irb = intel_renderbuffer(fb-_ColorDrawBuffers[0]);
-colorRegions[0] = (irb irb-region) ? irb-region : NULL;
- }
- }
-
- /* Check for depth fallback. */
- if (irbDepth irbDepth-region) {
- assert(!fb_has_hiz || irbDepth-Base.Format != MESA_FORMAT_S8_Z24);
- depthRegion = irbDepth-region;
- } else if (irbDepth !irbDepth-region) {
- depthRegion = NULL;
- } else { /* !irbDepth */
- /* No fallback is needed because there is no depth buffer. */
- depthRegion = NULL;
- }
-
- /* Check for stencil fallback. */
if (irbStencil irbStencil-region) {
if (!intel-has_separate_stencil)
assert(irbStencil-Base.Format == MESA_FORMAT_S8_Z24);
@@ -204,14 +154,6 @@ brw_update_draw_buffer(struct intel_context *intel)
assert(intel-has_separate_stencil);
}
- /* If we have a (packed) stencil buffer attached but no depth buffer,
-* we still need to set up the shared depth/stencil state so we can use it.
-*/
- if (depthRegion == NULL irbStencil irbStencil-region
-irbStencil-Base.Format == MESA_FORMAT_S8_Z24) {
- depthRegion = irbStencil-region;
- }
-
/*
* Update depth and stencil test state
*/
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/12] i965: Remove FALLBACK() from brw_update_draw_region().
The 965 driver doesn't use these for deciding on fallbacks.
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index ef1d4f6..1609938 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -183,24 +183,14 @@ brw_update_draw_buffer(struct intel_context *intel)
}
}
- if (!colorRegions[0]) {
- FALLBACK(intel, INTEL_FALLBACK_DRAW_BUFFER, GL_TRUE);
- }
- else {
- FALLBACK(intel, INTEL_FALLBACK_DRAW_BUFFER, GL_FALSE);
- }
-
/* Check for depth fallback. */
if (irbDepth irbDepth-region) {
assert(!fb_has_hiz || irbDepth-Base.Format != MESA_FORMAT_S8_Z24);
- FALLBACK(intel, INTEL_FALLBACK_DEPTH_BUFFER, GL_FALSE);
depthRegion = irbDepth-region;
} else if (irbDepth !irbDepth-region) {
- FALLBACK(intel, INTEL_FALLBACK_DEPTH_BUFFER, GL_TRUE);
depthRegion = NULL;
} else { /* !irbDepth */
/* No fallback is needed because there is no depth buffer. */
- FALLBACK(intel, INTEL_FALLBACK_DEPTH_BUFFER, GL_FALSE);
depthRegion = NULL;
}
@@ -212,12 +202,6 @@ brw_update_draw_buffer(struct intel_context *intel)
assert(irbStencil-Base.Format == MESA_FORMAT_S8);
if (irbStencil-Base.Format == MESA_FORMAT_S8)
assert(intel-has_separate_stencil);
- FALLBACK(intel, INTEL_FALLBACK_STENCIL_BUFFER, GL_FALSE);
- } else if (irbStencil !irbStencil-region) {
- FALLBACK(intel, INTEL_FALLBACK_STENCIL_BUFFER, GL_TRUE);
- } else { /* !irbStencil */
- /* No fallback is needed because there is no stencil buffer. */
- FALLBACK(intel, INTEL_FALLBACK_STENCIL_BUFFER, GL_FALSE);
}
/* If we have a (packed) stencil buffer attached but no depth buffer,
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/12] i965: Remove i915 paths from brw_update_draw_buffers().
---
src/mesa/drivers/dri/i965/brw_vtbl.c | 48 --
1 files changed, 11 insertions(+), 37 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 831c3e0..55dbd4f 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -154,51 +154,25 @@ brw_update_draw_buffer(struct intel_context *intel)
assert(intel-has_separate_stencil);
}
- /*
-* Update depth and stencil test state
+ /* Mesa's Stencil._Enabled field is updated when
+* _NEW_BUFFERS | _NEW_STENCIL, but i965 code assumes that the value
+* only changes with _NEW_STENCIL (which seems sensible). So flag it
+* here since this is the _NEW_BUFFERS path.
*/
- if (ctx-Driver.Enable) {
- ctx-Driver.Enable(ctx, GL_DEPTH_TEST,
- (ctx-Depth.Test fb-Visual.depthBits 0));
- ctx-Driver.Enable(ctx, GL_STENCIL_TEST,
- (ctx-Stencil.Enabled fb-Visual.stencilBits 0));
- }
- else {
- /* Mesa's Stencil._Enabled field is updated when
- * _NEW_BUFFERS | _NEW_STENCIL, but i965 code assumes that the value
- * only changes with _NEW_STENCIL (which seems sensible). So flag it
- * here since this is the _NEW_BUFFERS path.
- */
- intel-NewGLState |= (_NEW_DEPTH | _NEW_STENCIL);
- }
+ intel-NewGLState |= (_NEW_DEPTH | _NEW_STENCIL);
- intel-NewGLState |= _NEW_BUFFERS;
-
- /* update viewport since it depends on window size */
-#ifdef I915
- intelCalcViewport(ctx);
-#else
- intel-NewGLState |= _NEW_VIEWPORT;
-#endif
- /* Set state we know depends on drawable parameters:
+ /* The driver uses this in places that need to look up
+* renderbuffers' buffer objects.
*/
- if (ctx-Driver.Scissor)
- ctx-Driver.Scissor(ctx, ctx-Scissor.X, ctx-Scissor.Y,
- ctx-Scissor.Width, ctx-Scissor.Height);
- intel-NewGLState |= _NEW_SCISSOR;
+ intel-NewGLState |= _NEW_BUFFERS;
- if (ctx-Driver.DepthRange)
- ctx-Driver.DepthRange(ctx,
-ctx-Viewport.Near,
-ctx-Viewport.Far);
+ /* update viewport/scissor since it depends on window size */
+ intel-NewGLState |= _NEW_VIEWPORT | _NEW_SCISSOR;
/* Update culling direction which changes depending on the
* orientation of the buffer:
*/
- if (ctx-Driver.FrontFace)
- ctx-Driver.FrontFace(ctx, ctx-Polygon.FrontFace);
- else
- intel-NewGLState |= _NEW_POLYGON;
+ intel-NewGLState |= _NEW_POLYGON;
}
/**
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/12] i915: Disable the depth test whenever we don't have a depth buffer.
We were disabling it once at the moment we changed draw buffers, but later enabling of depth test could turn it back on. Fixes fbo-nodepth-test. Note that ctx-DrawBuffer has to be checked because during context create we get called while it's still unset. However, we know we'll get an intel_draw_buffer() after that, so it's safe to make a silly choice at this point. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30080 --- src/mesa/drivers/dri/i915/i915_state.c |7 +++ src/mesa/drivers/dri/i915/i915_vtbl.c |3 +-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i915/i915_state.c b/src/mesa/drivers/dri/i915/i915_state.c index 99212ad..73dda65 100644 --- a/src/mesa/drivers/dri/i915/i915_state.c +++ b/src/mesa/drivers/dri/i915/i915_state.c @@ -375,6 +375,9 @@ i915DepthMask(struct gl_context * ctx, GLboolean flag) DBG(%s flag (%d)\n, __FUNCTION__, flag); + if (!ctx-DrawBuffer || !ctx-DrawBuffer-Visual.depthBits) + flag = false; + dw = i915-state.Ctx[I915_CTXREG_LIS6]; if (flag ctx-Depth.Test) dw |= S6_DEPTH_WRITE_ENABLE; @@ -797,6 +800,10 @@ i915Enable(struct gl_context * ctx, GLenum cap, GLboolean state) case GL_DEPTH_TEST: dw = i915-state.Ctx[I915_CTXREG_LIS6]; + + if (!ctx-DrawBuffer || !ctx-DrawBuffer-Visual.depthBits) +state = false; + if (state) dw |= S6_DEPTH_TEST_ENABLE; else diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c b/src/mesa/drivers/dri/i915/i915_vtbl.c index dd030da..54cdf98 100644 --- a/src/mesa/drivers/dri/i915/i915_vtbl.c +++ b/src/mesa/drivers/dri/i915/i915_vtbl.c @@ -817,8 +817,7 @@ i915_update_draw_buffer(struct intel_context *intel) /* * Update depth and stencil test state */ - ctx-Driver.Enable(ctx, GL_DEPTH_TEST, - (ctx-Depth.Test fb-Visual.depthBits 0)); + ctx-Driver.Enable(ctx, GL_DEPTH_TEST, ctx-Depth.Test); ctx-Driver.Enable(ctx, GL_STENCIL_TEST, (ctx-Stencil.Enabled fb-Visual.stencilBits 0)); -- 1.7.5.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/12] i915: Make stencil test for no-stencil handling match depth test.
i915_update_draw_buffers() already handles the fallback bit for
missing stencil region, so here we just need to handle whether the GL
thinks we have stencil data or not (and disable the test if so).
---
src/mesa/drivers/dri/i915/i915_state.c | 32 +++-
src/mesa/drivers/dri/i915/i915_vtbl.c |3 +--
2 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_state.c
b/src/mesa/drivers/dri/i915/i915_state.c
index 73dda65..b876717 100644
--- a/src/mesa/drivers/dri/i915/i915_state.c
+++ b/src/mesa/drivers/dri/i915/i915_state.c
@@ -843,27 +843,17 @@ i915Enable(struct gl_context * ctx, GLenum cap, GLboolean
state)
break;
case GL_STENCIL_TEST:
- {
- GLboolean hw_stencil = GL_FALSE;
- if (ctx-DrawBuffer) {
-struct intel_renderbuffer *irbStencil
- = intel_get_renderbuffer(ctx-DrawBuffer, BUFFER_STENCIL);
-hw_stencil = (irbStencil irbStencil-region);
- }
- if (hw_stencil) {
- dw = i915-state.Ctx[I915_CTXREG_LIS5];
-if (state)
- dw |= (S5_STENCIL_TEST_ENABLE | S5_STENCIL_WRITE_ENABLE);
-else
- dw = ~(S5_STENCIL_TEST_ENABLE | S5_STENCIL_WRITE_ENABLE);
- if (dw != i915-state.Ctx[I915_CTXREG_LIS5]) {
- i915-state.Ctx[I915_CTXREG_LIS5] = dw;
- I915_STATECHANGE(i915, I915_UPLOAD_CTX);
- }
- }
- else {
-FALLBACK(i915-intel, I915_FALLBACK_STENCIL, state);
- }
+ if (!ctx-DrawBuffer || !ctx-DrawBuffer-Visual.stencilBits)
+state = false;
+
+ dw = i915-state.Ctx[I915_CTXREG_LIS5];
+ if (state)
+dw |= (S5_STENCIL_TEST_ENABLE | S5_STENCIL_WRITE_ENABLE);
+ else
+dw = ~(S5_STENCIL_TEST_ENABLE | S5_STENCIL_WRITE_ENABLE);
+ if (dw != i915-state.Ctx[I915_CTXREG_LIS5]) {
+i915-state.Ctx[I915_CTXREG_LIS5] = dw;
+I915_STATECHANGE(i915, I915_UPLOAD_CTX);
}
break;
diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c
b/src/mesa/drivers/dri/i915/i915_vtbl.c
index 54cdf98..e4a89b6 100644
--- a/src/mesa/drivers/dri/i915/i915_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
@@ -818,8 +818,7 @@ i915_update_draw_buffer(struct intel_context *intel)
* Update depth and stencil test state
*/
ctx-Driver.Enable(ctx, GL_DEPTH_TEST, ctx-Depth.Test);
- ctx-Driver.Enable(ctx, GL_STENCIL_TEST,
- (ctx-Stencil.Enabled fb-Visual.stencilBits 0));
+ ctx-Driver.Enable(ctx, GL_STENCIL_TEST, ctx-Stencil.Enabled);
intel-vtbl.set_draw_region(intel, colorRegions, depthRegion,
fb-_NumColorDrawBuffers);
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/12] i915: Remove i965 paths from i915_update_drawbuffer() and i830's too.
---
src/mesa/drivers/dri/i915/i830_vtbl.c | 46 +++-
src/mesa/drivers/dri/i915/i915_vtbl.c | 47 +++--
2 files changed, 20 insertions(+), 73 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
b/src/mesa/drivers/dri/i915/i830_vtbl.c
index 7dba135..2a97c6f 100644
--- a/src/mesa/drivers/dri/i915/i830_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i830_vtbl.c
@@ -825,12 +825,7 @@ i830_update_draw_buffer(struct intel_context *intel)
/* Check for stencil fallback. */
if (irbStencil irbStencil-region) {
- if (!intel-has_separate_stencil)
-assert(irbStencil-Base.Format == MESA_FORMAT_S8_Z24);
- if (fb_has_hiz || intel-must_use_separate_stencil)
-assert(irbStencil-Base.Format == MESA_FORMAT_S8);
- if (irbStencil-Base.Format == MESA_FORMAT_S8)
-assert(intel-has_separate_stencil);
+ assert(irbStencil-Base.Format == MESA_FORMAT_S8_Z24);
FALLBACK(intel, INTEL_FALLBACK_STENCIL_BUFFER, GL_FALSE);
} else if (irbStencil !irbStencil-region) {
FALLBACK(intel, INTEL_FALLBACK_STENCIL_BUFFER, GL_TRUE);
@@ -850,50 +845,29 @@ i830_update_draw_buffer(struct intel_context *intel)
/*
* Update depth and stencil test state
*/
- if (ctx-Driver.Enable) {
- ctx-Driver.Enable(ctx, GL_DEPTH_TEST,
- (ctx-Depth.Test fb-Visual.depthBits 0));
- ctx-Driver.Enable(ctx, GL_STENCIL_TEST,
- (ctx-Stencil.Enabled fb-Visual.stencilBits 0));
- }
- else {
- /* Mesa's Stencil._Enabled field is updated when
- * _NEW_BUFFERS | _NEW_STENCIL, but i965 code assumes that the value
- * only changes with _NEW_STENCIL (which seems sensible). So flag it
- * here since this is the _NEW_BUFFERS path.
- */
- intel-NewGLState |= (_NEW_DEPTH | _NEW_STENCIL);
- }
+ ctx-Driver.Enable(ctx, GL_DEPTH_TEST,
+ (ctx-Depth.Test fb-Visual.depthBits 0));
+ ctx-Driver.Enable(ctx, GL_STENCIL_TEST,
+ (ctx-Stencil.Enabled fb-Visual.stencilBits 0));
intel-vtbl.set_draw_region(intel, colorRegions, depthRegion,
fb-_NumColorDrawBuffers);
intel-NewGLState |= _NEW_BUFFERS;
/* update viewport since it depends on window size */
-#ifdef I915
intelCalcViewport(ctx);
-#else
- intel-NewGLState |= _NEW_VIEWPORT;
-#endif
+
/* Set state we know depends on drawable parameters:
*/
- if (ctx-Driver.Scissor)
- ctx-Driver.Scissor(ctx, ctx-Scissor.X, ctx-Scissor.Y,
- ctx-Scissor.Width, ctx-Scissor.Height);
- intel-NewGLState |= _NEW_SCISSOR;
+ ctx-Driver.Scissor(ctx, ctx-Scissor.X, ctx-Scissor.Y,
+ ctx-Scissor.Width, ctx-Scissor.Height);
- if (ctx-Driver.DepthRange)
- ctx-Driver.DepthRange(ctx,
-ctx-Viewport.Near,
-ctx-Viewport.Far);
+ ctx-Driver.DepthRange(ctx, ctx-Viewport.Near, ctx-Viewport.Far);
/* Update culling direction which changes depending on the
* orientation of the buffer:
*/
- if (ctx-Driver.FrontFace)
- ctx-Driver.FrontFace(ctx, ctx-Polygon.FrontFace);
- else
- intel-NewGLState |= _NEW_POLYGON;
+ ctx-Driver.FrontFace(ctx, ctx-Polygon.FrontFace);
}
/* This isn't really handled at the moment.
diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c
b/src/mesa/drivers/dri/i915/i915_vtbl.c
index c3df2aa..dd030da 100644
--- a/src/mesa/drivers/dri/i915/i915_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
@@ -797,12 +797,7 @@ i915_update_draw_buffer(struct intel_context *intel)
/* Check for stencil fallback. */
if (irbStencil irbStencil-region) {
- if (!intel-has_separate_stencil)
-assert(irbStencil-Base.Format == MESA_FORMAT_S8_Z24);
- if (fb_has_hiz || intel-must_use_separate_stencil)
-assert(irbStencil-Base.Format == MESA_FORMAT_S8);
- if (irbStencil-Base.Format == MESA_FORMAT_S8)
-assert(intel-has_separate_stencil);
+ assert(irbStencil-Base.Format == MESA_FORMAT_S8_Z24);
FALLBACK(intel, INTEL_FALLBACK_STENCIL_BUFFER, GL_FALSE);
} else if (irbStencil !irbStencil-region) {
FALLBACK(intel, INTEL_FALLBACK_STENCIL_BUFFER, GL_TRUE);
@@ -822,50 +817,28 @@ i915_update_draw_buffer(struct intel_context *intel)
/*
* Update depth and stencil test state
*/
- if (ctx-Driver.Enable) {
- ctx-Driver.Enable(ctx, GL_DEPTH_TEST,
- (ctx-Depth.Test fb-Visual.depthBits 0));
- ctx-Driver.Enable(ctx, GL_STENCIL_TEST,
- (ctx-Stencil.Enabled fb-Visual.stencilBits 0));
- }
- else {
- /* Mesa's Stencil._Enabled field is updated when
- * _NEW_BUFFERS | _NEW_STENCIL, but i965 code assumes that the value
- * only changes with _NEW_STENCIL (which seems sensible). So flag it
- * here since this is the _NEW_BUFFERS path.
-
[Mesa-dev] [PATCH 11/12] i915: Fix incorrect depth scaling when enabling/disabling depth buffers.
We were updating our new viewport using the old buffers' _WindowMap.m.
We can do less math and avoid using that deprecated matrix by just
folding the viewport calculation right in to the driver.
Fixes piglit fbo-depthtex.
---
src/mesa/drivers/dri/i915/i915_state.c | 43 ++-
1 files changed, 19 insertions(+), 24 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_state.c
b/src/mesa/drivers/dri/i915/i915_state.c
index b876717..2b35ed7 100644
--- a/src/mesa/drivers/dri/i915/i915_state.c
+++ b/src/mesa/drivers/dri/i915/i915_state.c
@@ -401,31 +401,26 @@ void
intelCalcViewport(struct gl_context * ctx)
{
struct intel_context *intel = intel_context(ctx);
- const GLfloat *v = ctx-Viewport._WindowMap.m;
- const GLfloat depthScale = 1.0F / ctx-DrawBuffer-_DepthMaxF;
- GLfloat *m = intel-ViewportMatrix.m;
- GLfloat yScale, yBias;
-
- if (ctx-DrawBuffer-Name) {
- /* User created FBO */
- /* y=0=bottom */
- yScale = 1.0;
- yBias = 0.0;
- }
- else {
- /* window buffer, y=0=top */
- yScale = -1.0;
- yBias = ctx-DrawBuffer-Height;
- }
-
- m[MAT_SX] = v[MAT_SX];
- m[MAT_TX] = v[MAT_TX];
- m[MAT_SY] = v[MAT_SY] * yScale;
- m[MAT_TY] = v[MAT_TY] * yScale + yBias;
-
- m[MAT_SZ] = v[MAT_SZ] * depthScale;
- m[MAT_TZ] = v[MAT_TZ] * depthScale;
+ if (ctx-DrawBuffer-Name == 0) {
+ _math_matrix_viewport(intel-ViewportMatrix,
+ ctx-Viewport.X,
+ ctx-DrawBuffer-Height - ctx-Viewport.Y,
+ ctx-Viewport.Width,
+ -ctx-Viewport.Height,
+ ctx-Viewport.Near,
+ ctx-Viewport.Far,
+ 1.0);
+ } else {
+ _math_matrix_viewport(intel-ViewportMatrix,
+ ctx-Viewport.X,
+ ctx-Viewport.Y,
+ ctx-Viewport.Width,
+ ctx-Viewport.Height,
+ ctx-Viewport.Near,
+ ctx-Viewport.Far,
+ 1.0);
+ }
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/12] i915: Add support for HW rendering with no color draw buffer.
This is useful for shadow map generation. Tested with glsl-bug-22603,
which rendered the depth textures with fallbacks before.
---
src/mesa/drivers/dri/i915/i915_vtbl.c | 98 +
1 files changed, 50 insertions(+), 48 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c
b/src/mesa/drivers/dri/i915/i915_vtbl.c
index e4a89b6..4528113 100644
--- a/src/mesa/drivers/dri/i915/i915_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
@@ -318,7 +318,8 @@ i915_emit_state(struct intel_context *intel)
aper_array[aper_count++] = intel-batch.bo;
if (dirty I915_UPLOAD_BUFFERS) {
- aper_array[aper_count++] = state-draw_region-buffer;
+ if (state-draw_region)
+aper_array[aper_count++] = state-draw_region-buffer;
if (state-depth_region)
aper_array[aper_count++] = state-depth_region-buffer;
}
@@ -388,23 +389,27 @@ i915_emit_state(struct intel_context *intel)
if (INTEL_DEBUG DEBUG_STATE)
fprintf(stderr, I915_UPLOAD_BUFFERS:\n);
- count = 14;
+ count = 17;
if (state-Buffer[I915_DESTREG_DRAWRECT0] != MI_NOOP)
count++;
- if (state-depth_region)
- count += 3;
BEGIN_BATCH(count);
OUT_BATCH(state-Buffer[I915_DESTREG_CBUFADDR0]);
OUT_BATCH(state-Buffer[I915_DESTREG_CBUFADDR1]);
- OUT_RELOC(state-draw_region-buffer,
- I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0);
+ if (state-draw_region) {
+OUT_RELOC(state-draw_region-buffer,
+ I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0);
+ } else {
+OUT_BATCH(0);
+ }
+ OUT_BATCH(state-Buffer[I915_DESTREG_DBUFADDR0]);
+ OUT_BATCH(state-Buffer[I915_DESTREG_DBUFADDR1]);
if (state-depth_region) {
- OUT_BATCH(state-Buffer[I915_DESTREG_DBUFADDR0]);
- OUT_BATCH(state-Buffer[I915_DESTREG_DBUFADDR1]);
OUT_RELOC(state-depth_region-buffer,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0);
+ } else {
+OUT_BATCH(0);
}
OUT_BATCH(state-Buffer[I915_DESTREG_DV0]);
@@ -532,6 +537,12 @@ i915_set_buf_info_for_region(uint32_t *state, struct
intel_region *region,
if (region-tiling == I915_TILING_Y)
state[1] |= BUF_3D_TILE_WALK_Y;
}
+ } else {
+ /* Fill in a default pitch, since 0 is invalid. We'll be
+ * setting the buffer offset to 0 and not referencing the
+ * buffer, so the pitch could really be any valid value.
+ */
+ state[1] |= BUF_3D_PITCH(4096);
}
}
@@ -596,6 +607,8 @@ i915_set_draw_region(struct intel_context *intel,
LOD_PRECLAMP_OGL | TEX_DEFAULT_COLOR_OGL);
if (irb != NULL) {
value |= i915_render_target_format_for_mesa_format[irb-Base.Format];
+ } else {
+ value |= DV_PF_;
}
/* This isn't quite safe, thus being hidden behind an option. When changing
@@ -670,6 +683,20 @@ i915_set_draw_region(struct intel_context *intel,
I915_STATECHANGE(i915, I915_UPLOAD_BUFFERS);
}
+static void
+i915_update_color_write_enable(struct i915_context *i915, bool enable)
+{
+ uint32_t dw = i915-state.Ctx[I915_CTXREG_LIS6];
+ if (enable)
+ dw |= S6_COLOR_WRITE_ENABLE;
+ else
+ dw = ~S6_COLOR_WRITE_ENABLE;
+ if (dw != i915-state.Ctx[I915_CTXREG_LIS6]) {
+ I915_STATECHANGE(i915, I915_UPLOAD_CTX);
+ i915-state.Ctx[I915_CTXREG_LIS6] = dw;
+ }
+}
+
/**
* Update the hardware state for drawing into a window or framebuffer object.
*
@@ -683,9 +710,10 @@ i915_set_draw_region(struct intel_context *intel,
static void
i915_update_draw_buffer(struct intel_context *intel)
{
+ struct i915_context *i915 = (struct i915_context *)intel;
struct gl_context *ctx = intel-ctx;
struct gl_framebuffer *fb = ctx-DrawBuffer;
- struct intel_region *colorRegions[MAX_DRAW_BUFFERS], *depthRegion = NULL;
+ struct intel_region *colorRegion = NULL, *depthRegion = NULL;
struct intel_renderbuffer *irbDepth = NULL, *irbStencil = NULL;
bool fb_has_hiz = intel_framebuffer_has_hiz(fb);
@@ -741,44 +769,16 @@ i915_update_draw_buffer(struct intel_context *intel)
* having regions set makes some of the software fallback paths faster.
*/
if ((fb-Width ctx-Const.MaxRenderbufferSize)
- || (fb-Height ctx-Const.MaxRenderbufferSize)
- || (fb-_NumColorDrawBuffers == 0)) {
- /* writing to 0 */
- colorRegions[0] = NULL;
- }
- else if (fb-_NumColorDrawBuffers 1) {
- int i;
- struct intel_renderbuffer *irb;
-
- for (i = 0; i fb-_NumColorDrawBuffers; i++) {
- irb = intel_renderbuffer(fb-_ColorDrawBuffers[i]);
- colorRegions[i] = irb ? irb-region : NULL;
- }
- }
- else {
- /* Get the intel_renderbuffer for the single colorbuffer we're drawing
- * into.
- */
- if (fb-Name == 0) {
-/* drawing to window system buffer */
-if
Re: [Mesa-dev] robust-tarballs branch (Was: Error building on Windows with SCons)
- Original Message -
Hi Jose,
On Sat, Jul 9, 2011 at 6:03 AM, Jose Fonseca jfons...@vmware.com
wrote:
I heard no concerns so I went ahead and made a branch where:
- I removed GLUT
- derived Mesa tarballs' file list from git ls-files.
http://cgit.freedesktop.org/mesa/mesa/log/?h=robust-tarballs
I've confirmed that both automake and scons+crossmingw32 build
correctly on Linux.
I'd like to merge to main if there are no objections.
Having a brief look through the commits, it looks like a lot of nice
cleanup. A couple comments.
Thanks Dan
26edecac589819f0d0efe2165ab748dbc4e53394:
Using the variable DIRECTORY is a little confusing since it's a
symlink. DIRLINK may be better.
I agree DIRECTORY is not a very descriptive -- it was simply variable name
already being used before. DIRLINK doesn't explain much more so I went for the
typical PACKAGE_{VERSION/DIR/NAME}
34983337f9d7db984e9f0117808274106d262110:
- src/mesa/depend is in EXTRA_FILES. This seems like something that
shouldn't be shipped.
I've added because master's Makefile has it:
MAIN_FILES = \
[...]
$(DIRECTORY)/src/mesa/depend\
I thought there was some obscure need. I removed it now.
- You're passing -x autogen.sh to not ship autogen.sh, but is that
the only thing that shouldn't be disted?
I'm also skipping all .dotfiles files.
Any chance you could compare
an old tarball to a new tarball and see if any unintended new files
slipped in?
Yes. I did compare. There is more doc files, and additional test programs. I
personally don't see reason why not to dist, but exceptions can be easily added.
I confess I was more concerned with all the stuff that should be disted and
wasn't -- that was my main motive for doing the cleanup.
- This might be for another commit, but it would be nice to move that
to a separate variable. To start it could be hacky with the arguments
embedded:
IGNORE_FILES = \
-x autogen.sh \
-x otherunwantedfile
Done.
- $(LIBNAME).zip should depend on manifest.txt
Good catch.
Looks good otherwise, though.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Case where opt_copy_propagation doesn't do its job
On 07/12/2011 04:36 PM, Eric Anholt wrote: On Tue, 12 Jul 2011 15:44:12 -0500, Bryan Cain bryanca...@gmail.com wrote: It appears that the copy propagation pass in the GLSL compiler (in opt_copy_propagation.cpp) doesn't do copy propagation when the components of a variable are initialized separately, like this: (declare (temporary ) vec4 vec_ctor) (assign (w) (var_ref vec_ctor) (constant float (1.00)) ) (assign (xyz) (var_ref vec_ctor) (var_ref assignment_tmp@16) ) (assign (xyzw) (var_ref gl_FragColor) (var_ref vec_ctor) ) In the past, this wasn't visible in the Mesa IR output because Mesa IR optimization seems to do the copy propagation. However, glsl_to_tgsi doesn't do copy propagation to output registers - in fact, I believe this is the only case left where ir_to_mesa produces better code than glsl_to_tgsi. I'm not very enthusiastic about the idea adding to the copy propagation pass in glsl_to_tgsi, since this case is something that should really be optimized by the GLSL compiler before it reaches the IR backend. So, is there a reason why the GLSL copy propagation pass doesn't operate per-component? opt_copy_propagation_elements does that, but it doesn't split up the assignment into multiple assignments (otherwise, imagine initializing vec_ctor once and using it many times -- how do you decide whether copy propagate or not, to avoid pessimizing the code?). I think the operation you're looking for isn't really copy propagation, but more like register coalescing where you see that vec_ctor doesn't get redefined and used after being assigned to gl_FragColor, and just store the two in the same place. And yes, I think it would be useful to have something like that. Oops, I don't have a very good vocabulary of compiler terms, and after looking at the file I started to realize it wasn't copy propagation I was looking for. But you're right, that's a good idea, and maybe I can try writing a pass for that. If I'm thinking about this right, it would just track which variables are only dereferenced once, and where that dereference is in an assignment; then it would change the LHS of the assignment(s) to the first variable and replace it with the new one. Actually, if that were done for all variables, it would involve tracking whether the second variable is used in between assignment and dereference of the first variable. So I think I'll just do it for ir_var_out variables instead. They're the only ones that are causing me a problem, anyway. Either that or generate new ir_quadop_vector in copy propagation. I don't understand how that solution would work. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
