Re: [Mesa3d-dev] regression in r600g with a22aba4eae9b29db731487bce90e8292f7e82c72
On Sun, Apr 24, 2011 at 10:08 AM, Marek Olšák mar...@gmail.com wrote: On Sun, Apr 24, 2011 at 1:15 AM, Dave Airlie airl...@gmail.com wrote: Hi Brian, st/mesa: check image size before copy_image_data_to_texture() This causes a regression with NPOT textures in fbo-generate-mipmaps on r600g. FWIW r300g and softpipe are broken too. The issue seems to be driver-independent. Testing 3 (NPOT) wtf 293 277 1 vs 292 276 1 wtf 293 277 1 vs 292 276 1 wtf 293 277 1 vs 292 276 1 So the first set of values is from the stImage and the second set are the minified values, so we don't copy because they are off by one. Dave. Marek -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] regression in r600g with a22aba4eae9b29db731487bce90e8292f7e82c72
Hi Brian, st/mesa: check image size before copy_image_data_to_texture() This causes a regression with NPOT textures in fbo-generate-mipmaps on r600g. Please don't put it into 7.10 until we can figure out why, but I'm guessing the restrictions are too strict. Dave. -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Tue, Apr 13, 2010 at 11:42 PM, Roland Scheidegger srol...@vmware.com wrote: On 13.04.2010 02:52, Dave Airlie wrote: On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul bri...@vmware.com wrote: Dave Airlie wrote: Just going down the r300g piglit failures and noticed fbo-drawbuffers failed, I've no idea if this passes on Intel hw, but it appears the texenvprogram really needs to understand the draw buffers. The attached patch fixes it here for me on r300g anyone want to test this on Intel with the piglit test before/after? The piglit test passes as-is with Mesa/swrast and NVIDIA. It fails with gallium/softpipe both with and w/out your patch. I think that your patch is on the right track. But multiple render targets are still a bit of an untested area in the st/mesa code. One thing: the patch introduces a dependency on buffer state in the texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag. Otherwise, I'd like to debug the softpipe failure a bit further to see what's going on. Perhaps you could hold off on committing this for a bit... Well Eric pointed out to me the fun line in the spec (3) Should gl_FragColor be aliased to gl_FragData[0]? RESOLUTION: No. A shader should write either gl_FragColor, or gl_FragData[n], but not both. Writing to gl_FragColor will write to all draw buffers specified with DrawBuffersARB. So I was really just masking the issue with this. From what I can see softpipe messes up and I'm not sure where we should be fixing this. swrast does okay, its just whether we should be doing something in gallium or in the drivers is open. Hmm yes looks like that's not really well defined. I guess there are several options here: 1) don't do anything at the state tracker level, and assume that if a fragment shader only writes to color 0 but has several color buffers bound the color is meant to go to all outputs. Looks like that's what nv50 is doing today. If a shader writes to FragData[0] but not others, in gallium that would mean that output still gets replicated to all outputs, but since the spec says unwritten outputs are undefined that would be just fine (for OpenGL - not sure about other APIs). 2) Use some explicit means to distinguish FragData[] from FragColor in gallium. For instance, could use different semantic name (like TGSI_SEMANTIC_COLOR and TGSI_SEMANTIC_GENERIC for the respective outputs). Or could have a flag somewhere (not quite sure where) saying if color output is to be replicated to all buffers. 3) Translate away the single color output in state tracker to multiple outputs. I don't like option 3) though. Means we need to recompile if the attached buffers change. Moreover, it seems both new nvidia and AMD chips (r600 has MULTIWRITE_ENABLE bit) handle this just fine in hw. I don't like option 1) neither, that kind of implicit behavior might be ok but this kind of guesswork isn't very nice imho. Yeah 3 is definitely out, I've tried it its too messy, esp with 1-n and n-1 transitions, I'd be happy with 1 or 2, though I do wonder with 1 do you end up binding Color and Data0 implicitly say you bound 2 buffers but your fragprog only emits to one on purpose (maybe you have a few fragprogs). So I expect 2 is the correct answer. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Wed, Apr 14, 2010 at 8:33 AM, Roland Scheidegger srol...@vmware.com wrote:
On 13.04.2010 20:28, Alex Deucher wrote:
On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger srol...@vmware.com
wrote:
On 13.04.2010 02:52, Dave Airlie wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul bri...@vmware.com wrote:
Dave Airlie wrote:
Just going down the r300g piglit failures and noticed fbo-drawbuffers
failed, I've no idea
if this passes on Intel hw, but it appears the texenvprogram really
needs to understand the
draw buffers. The attached patch fixes it here for me on r300g anyone
want to test this on Intel
with the piglit test before/after?
The piglit test passes as-is with Mesa/swrast and NVIDIA.
It fails with gallium/softpipe both with and w/out your patch.
I think that your patch is on the right track. But multiple render
targets
are still a bit of an untested area in the st/mesa code.
One thing: the patch introduces a dependency on buffer state in the
texenvprogram code so in state.c we should check for the _NEW_BUFFERS
flag.
Otherwise, I'd like to debug the softpipe failure a bit further to see
what's going on. Perhaps you could hold off on committing this for a
bit...
Well Eric pointed out to me the fun line in the spec
(3) Should gl_FragColor be aliased to gl_FragData[0]?
RESOLUTION: No. A shader should write either gl_FragColor, or
gl_FragData[n], but not both.
Writing to gl_FragColor will write to all draw buffers specified
with DrawBuffersARB.
So I was really just masking the issue with this. From what I can see
softpipe messes up and I'm not sure where we should be fixing this.
swrast does okay, its just whether we should be doing something in gallium
or in the drivers is open.
Hmm yes looks like that's not really well defined. I guess there are
several options here:
1) don't do anything at the state tracker level, and assume that if a
fragment shader only writes to color 0 but has several color buffers
bound the color is meant to go to all outputs. Looks like that's what
nv50 is doing today. If a shader writes to FragData[0] but not others,
in gallium that would mean that output still gets replicated to all
outputs, but since the spec says unwritten outputs are undefined that
would be just fine (for OpenGL - not sure about other APIs).
2) Use some explicit means to distinguish FragData[] from FragColor in
gallium. For instance, could use different semantic name (like
TGSI_SEMANTIC_COLOR and TGSI_SEMANTIC_GENERIC for the respective
outputs). Or could have a flag somewhere (not quite sure where) saying
if color output is to be replicated to all buffers.
3) Translate away the single color output in state tracker to multiple
outputs.
I don't like option 3) though. Means we need to recompile if the
attached buffers change. Moreover, it seems both new nvidia and AMD
chips (r600 has MULTIWRITE_ENABLE bit) handle this just fine in hw.
I don't like option 1) neither, that kind of implicit behavior might be
ok but this kind of guesswork isn't very nice imho.
Whatever's easiest, just document it. I'd be cool with:
DECL IN[0], COLOR, PERSPECTIVE
DECL OUT[0], COLOR
MOV OUT[0], IN[0]
END
Effectively being a write to all color buffers, however, this one from
progs/tests/drawbuffers:
DCL IN[0], COLOR, LINEAR
DCL OUT[0], COLOR
DCL OUT[1], COLOR[1]
IMM FLT32 { 1., 0., 0., 0. }
0: MOV OUT[0], IN[0]
1: SUB OUT[1], IMM[0]., IN[0]
2: END
Would then double-write the second color buffer. Unpleasant. Language
like this would work, I suppose?
If only one color output is declared, writes to the color output shall
be redirected to all bound color buffers. Otherwise, color outputs
shall be bound to their specific color buffer.
Also, keep in mind that writing to multiple color buffers uses
additional memory bandwidth, so for performance, we should only do so
when required.
Do apps really have several color buffers bound but only write to one,
leaving the state of the others undefined in the process? Sounds like a
poor app to begin with to me.
Actually, I would restrict that language above further, so only color
output 0 will get redirected to all buffers if it's the only one
written. As said though I'd think some explicit bits somewhere are
cleaner. I'm not yet sure that the above would really work for all APIs,
it is possible some say other buffers not written to are left as is
instead of undefined.
Who knows, the GL API allows for it, I don't see how we can
arbitrarily decide to restrict it.
I could write an app that uses multiple fragment programs, and
switches between them, with two outputs buffers bound, though I'm
possibly constructing something very arbitary.
The ARB_draw_buffers explicitly states that Data0 != Color.
Dave.
Roland
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul bri...@vmware.com wrote: Dave Airlie wrote: Just going down the r300g piglit failures and noticed fbo-drawbuffers failed, I've no idea if this passes on Intel hw, but it appears the texenvprogram really needs to understand the draw buffers. The attached patch fixes it here for me on r300g anyone want to test this on Intel with the piglit test before/after? The piglit test passes as-is with Mesa/swrast and NVIDIA. It fails with gallium/softpipe both with and w/out your patch. I think that your patch is on the right track. But multiple render targets are still a bit of an untested area in the st/mesa code. One thing: the patch introduces a dependency on buffer state in the texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag. Otherwise, I'd like to debug the softpipe failure a bit further to see what's going on. Perhaps you could hold off on committing this for a bit... Well Eric pointed out to me the fun line in the spec (3) Should gl_FragColor be aliased to gl_FragData[0]? RESOLUTION: No. A shader should write either gl_FragColor, or gl_FragData[n], but not both. Writing to gl_FragColor will write to all draw buffers specified with DrawBuffersARB. So I was really just masking the issue with this. From what I can see softpipe messes up and I'm not sure where we should be fixing this. swrast does okay, its just whether we should be doing something in gallium or in the drivers is open. From what I can see i965 + r300-r500 and at least nv40 from talking to Ben would need fragment program changes to emit to each buffer instead. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
(3) Should gl_FragColor be aliased to gl_FragData[0]? RESOLUTION: No. A shader should write either gl_FragColor, or gl_FragData[n], but not both. Writing to gl_FragColor will write to all draw buffers specified with DrawBuffersARB. So I was really just masking the issue with this. From what I can see softpipe messes up and I'm not sure where we should be fixing this. swrast does okay, its just whether we should be doing something in gallium or in the drivers is open. From what I can see i965 + r300-r500 and at least nv40 from talking to Ben would need fragment program changes to emit to each buffer instead. Okay I'm failing to get this to work, I'll run down the ideas I had so far that failed. 1. Have the mesa state tracker add the extra output instructions to the fragment program at compile time. Failed: no where to actually invalidate the current fragment program. 2. Add a flag to mesa context and have mesa add the extra output instructions at compile time (prog parser + texenvprogram). Failed: no where to tell that the FP needs updating has changed so needs to be recompiled. this works for texenvprog but fails for user programs. Now the other place to do this is like i965 does, in the driver but from a gallium pov it seems like something the state tracker should deal with at TGSI doesn't seem to care about the nuance between FRAG_OUTPUT_COLOR and FRAG_OUTPUT_DATAx http://people.freedesktop.org/~airlied/fp-convert-color-data-fail-one.patch Has the fail for case 2, the programopt.c changes are most likely correct, and I guess I can do option 1 with some sort of state tracker program invalidation (i.e. freeing the TGSI tokens and letting it get recompiled.) Ideas? Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] piglit linking
So I don't understand cmake, but there is a lot of implicit linking going on in piglit, and in Fedora 13 our linker doesn't like that anymore. So for example the fp-rfl test uses sqrt which means it needs to link to libm not get libm via other links, glx-multithread needs to link to pthread etc. How do I add per-app linking clauses to the cmake files? Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB draw buffers + texenv program
On Tue, Apr 6, 2010 at 10:47 PM, Keith Whitwell kei...@vmware.com wrote: On Fri, 2010-04-02 at 20:43 -0700, Dave Airlie wrote: Just going down the r300g piglit failures and noticed fbo-drawbuffers failed, I've no idea if this passes on Intel hw, but it appears the texenvprogram really needs to understand the draw buffers. The attached patch fixes it here for me on r300g anyone want to test this on Intel with the piglit test before/after? Dave. This change makes sense looks good to me. Thanks pushed to 7.8. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2
On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu olva...@gmail.com wrote: On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie airl...@gmail.com wrote: On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu olva...@gmail.com wrote: On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie airl...@gmail.com wrote: The attached patch fixes tfp test for me (with i915g). Could you see if r300g passes the test with the patch? The teximage callback has an internal_format parameter that specifies how the pipe texture should be treated. It can differ from the format of the texture. It seems to suffice for TFP. I was lazy enough not to use it :( That was my first attempt also, however it fails as the texture is already created, and in r300g we already have worked out the hw state assuming the texture format won't change. This seems to be what gallium expects. So in this case you end up recreating a new texture at finalise because the formats don't match and you lose the pixmap. r300g does not see the texture before st_finalize_texture, right? It seems to me that the patch should give the correct behavior but a (really bad) unnecessary texture copy in st_finalize_texture. Could we avoid the copy by solely changing the sampler view? It sees the texture via dri_st_framebuffer_validate_att(drawable-stfb, ST_ATTACHMENT_FRONT_LEFT) which causes the texture to be creates from the dri2 buffer handle, The thing is we need the exact buffer object we get from the X server, we can't copy it to another texture later, as it destroys the shared texture and just seems to create another private one. Suppose a PIPE_FORMAT_B8G8R8A8_UNORM GLXPixmap is created both for rendering, and t-f-p texturing with GLX_TEXTURE_FORMAT_RGB_EXT. The front left buffer of the pixmap should be a single PIPE_FORMAT_B8G8R8A8_UNORM pipe_texture. When glXBindTexImageEXT is called, st/mesa should view the pipe_texture as if there is no alpha channel. It is hacky for st/dri to create another pipe_texture from the same dri2 buffer handle with a different format and pass the new pipe_texture to st/mesa. To achieve the viewing thing efficiently, st/mesa should create a PIPE_FORMAT_B8G8R8X8_UNORM sampler view for the pipe_texture (I suppose this is what a sampler view for? No?). This is contrary to performing an implicit copy on the pipe_texture only to ignore the alpha channel, which is what st_finalize_texture does. IIRC, tfp allows an implementation to perform an implicit copy upon binding. Both behaviors are correct in this sense, but the latter is obviously undesirable. Yes a sampler view seems the sanest. The latter behaviour might be correct but doesn't work here, at least with the equiv patch I tried originally the test still failed, so it would be correct if it worked though slower. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2
On Mon, Apr 5, 2010 at 6:06 PM, Chia-I Wu olva...@gmail.com wrote: On Mon, Apr 5, 2010 at 3:38 PM, Dave Airlie airl...@gmail.com wrote: On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu olva...@gmail.com wrote: On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie airl...@gmail.com wrote: On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu olva...@gmail.com wrote: On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie airl...@gmail.com wrote: The attached patch fixes tfp test for me (with i915g). Could you see if r300g passes the test with the patch? The teximage callback has an internal_format parameter that specifies how the pipe texture should be treated. It can differ from the format of the texture. It seems to suffice for TFP. I was lazy enough not to use it :( That was my first attempt also, however it fails as the texture is already created, and in r300g we already have worked out the hw state assuming the texture format won't change. This seems to be what gallium expects. So in this case you end up recreating a new texture at finalise because the formats don't match and you lose the pixmap. r300g does not see the texture before st_finalize_texture, right? It seems to me that the patch should give the correct behavior but a (really bad) unnecessary texture copy in st_finalize_texture. Could we avoid the copy by solely changing the sampler view? It sees the texture via dri_st_framebuffer_validate_att(drawable-stfb, ST_ATTACHMENT_FRONT_LEFT) which causes the texture to be creates from the dri2 buffer handle, The thing is we need the exact buffer object we get from the X server, we can't copy it to another texture later, as it destroys the shared texture and just seems to create another private one. Suppose a PIPE_FORMAT_B8G8R8A8_UNORM GLXPixmap is created both for rendering, and t-f-p texturing with GLX_TEXTURE_FORMAT_RGB_EXT. The front left buffer of the pixmap should be a single PIPE_FORMAT_B8G8R8A8_UNORM pipe_texture. When glXBindTexImageEXT is called, st/mesa should view the pipe_texture as if there is no alpha channel. It is hacky for st/dri to create another pipe_texture from the same dri2 buffer handle with a different format and pass the new pipe_texture to st/mesa. To achieve the viewing thing efficiently, st/mesa should create a PIPE_FORMAT_B8G8R8X8_UNORM sampler view for the pipe_texture (I suppose this is what a sampler view for? No?). This is contrary to performing an implicit copy on the pipe_texture only to ignore the alpha channel, which is what st_finalize_texture does. IIRC, tfp allows an implementation to perform an implicit copy upon binding. Both behaviors are correct in this sense, but the latter is obviously undesirable. Yes a sampler view seems the sanest. The latter behaviour might be correct but doesn't work here, at least with the equiv patch I tried originally the test still failed, so it would be correct if it worked though slower. The patch I sent earlier works here with i915g. I am not sure where it goes wrong with r300g. Do you mind have a look into it? Yeah I suspect we have an issue in r300g alright, we use a stride override when we get the texture from TFP, and this might not be propogated properly when we copy it later. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] dri2 st + tfp set tex buffer2
Hey, So I was trying to fix tfp test on r300g, and ran into an issue with dri st I think. So the way TFP works we get dri2_set_tex_buffer, which then validates the attachment, but ignores the format passed in. So r300g picks up the kernel buffer from the handle and sets up the texture + texture state without the format information. Once we've validated, we call ctx-st-teximage and can give it a different format however at no point does r300g get any place to change the texture format and update its internal state. I'm not sure if either r300g should delay setting up its internal state for emission until later or whether we need to enhance the st interface. The main issue with we get a TFP with a B8G8R8X8 but the visual is B8G8R8A8 which triggers this. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2
On Sun, Apr 4, 2010 at 8:31 PM, Dave Airlie airl...@gmail.com wrote: Hey, So I was trying to fix tfp test on r300g, and ran into an issue with dri st I think. So the way TFP works we get dri2_set_tex_buffer, which then validates the attachment, but ignores the format passed in. So r300g picks up the kernel buffer from the handle and sets up the texture + texture state without the format information. Once we've validated, we call ctx-st-teximage and can give it a different format however at no point does r300g get any place to change the texture format and update its internal state. I'm not sure if either r300g should delay setting up its internal state for emission until later or whether we need to enhance the st interface. The main issue with we get a TFP with a B8G8R8X8 but the visual is B8G8R8A8 which triggers this. Here's a hacky patch to demonstrate the issue, though it doesn't fix the problem I'm seeing with the test, just one less thing wrong. Dave. 0001-dri-st-add-hacky-tfp-format-override.patch Description: Binary data -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2
Here's a hacky patch to demonstrate the issue, though it doesn't fix the problem I'm seeing with the test, just one less thing wrong. Here's a second patch that actually fixes the piglit tfp test for me on r300g. Dave. 0001-dri-st-add-hacky-tfp-format-override-v2.patch Description: Binary data -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] segfault in readpix demo with GL_OES_read_format on r300g
Starting program: /home/airlied/mesa/progs/demos/readpix [Thread debugging using libthread_db enabled] GL_VERSION = 2.1 Mesa 7.9-devel GL_RENDERER = Gallium 0.4 on RV530 Program received signal SIGSEGV, Segmentation fault. 0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38) at main/framebuffer.c:1021 1021} Missing separate debuginfos, use: debuginfo-install expat-2.0.1-8.fc12.i686 libICE-1.0.6-1.fc12.i686 libSM-1.1.0-7.fc12.i686 libX11-1.3-1.fc12.i686 libXdamage-1.1.2-1.fc12.i686 libXext-1.1-2.fc12.i686 libXfixes-4.0.4-1.fc12.i686 libXi-1.3-2.fc12.i686 libXmu-1.0.5-1.fc12.i686 libXt-1.0.7-1.fc12.i686 libXxf86vm-1.1.0-1.fc12.i686 libgcc-4.4.3-4.fc12.i686 libstdc++-4.4.3-4.fc12.i686 libuuid-2.16.2-5.fc12.i686 libxcb-1.5-1.fc12.i686 (gdb) bt #0 0xb7cc13dd in _mesa_get_color_read_type (ctx=0x8086e38) at main/framebuffer.c:1021 #1 0xb7d75758 in _mesa_GetIntegerv (pname=35738, params=0x804c41c) at main/get.c:5576 #2 0x080493ae in Init (argc=1, argv=0xb2b4) at readpix.c:354 #3 main (argc=1, argv=0xb2b4) at readpix.c:396 (gdb) Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2
On Mon, Apr 5, 2010 at 12:49 PM, Chia-I Wu olva...@gmail.com wrote: On Sun, Apr 4, 2010 at 6:31 PM, Dave Airlie airl...@gmail.com wrote: Hey, So I was trying to fix tfp test on r300g, and ran into an issue with dri st I think. So the way TFP works we get dri2_set_tex_buffer, which then validates the attachment, but ignores the format passed in. So r300g picks up the kernel buffer from the handle and sets up the texture + texture state without the format information. Once we've validated, we call ctx-st-teximage and can give it a different format however at no point does r300g get any place to change the texture format and update its internal state. I'm not sure if either r300g should delay setting up its internal state for emission until later or whether we need to enhance the st interface. The main issue with we get a TFP with a B8G8R8X8 but the visual is B8G8R8A8 which triggers this. The attached patch fixes tfp test for me (with i915g). Could you see if r300g passes the test with the patch? The teximage callback has an internal_format parameter that specifies how the pipe texture should be treated. It can differ from the format of the texture. It seems to suffice for TFP. I was lazy enough not to use it :( That was my first attempt also, however it fails as the texture is already created, and in r300g we already have worked out the hw state assuming the texture format won't change. This seems to be what gallium expects. So in this case you end up recreating a new texture at finalise because the formats don't match and you lose the pixmap. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2
On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu olva...@gmail.com wrote: On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie airl...@gmail.com wrote: The attached patch fixes tfp test for me (with i915g). Could you see if r300g passes the test with the patch? The teximage callback has an internal_format parameter that specifies how the pipe texture should be treated. It can differ from the format of the texture. It seems to suffice for TFP. I was lazy enough not to use it :( That was my first attempt also, however it fails as the texture is already created, and in r300g we already have worked out the hw state assuming the texture format won't change. This seems to be what gallium expects. So in this case you end up recreating a new texture at finalise because the formats don't match and you lose the pixmap. r300g does not see the texture before st_finalize_texture, right? It seems to me that the patch should give the correct behavior but a (really bad) unnecessary texture copy in st_finalize_texture. Could we avoid the copy by solely changing the sampler view? It sees the texture via dri_st_framebuffer_validate_att(drawable-stfb, ST_ATTACHMENT_FRONT_LEFT) which causes the texture to be creates from the dri2 buffer handle, The thing is we need the exact buffer object we get from the X server, we can't copy it to another texture later, as it destroys the shared texture and just seems to create another private one. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium + dri2 front buffer readback
The piglit read-front.c test is failing and the rabbits warren that is
front buffer rendering in mesa st + dri st isn't helping me solve it.
One thing I noticed was check_create_front_buffers is called in a
number of places in the st, however it seems to never be used, as we
call st_manager_add_color_renderbuffer moments before and that sets up
the buffer.
so
if (fb-Attachment[frontIndex].Renderbuffer == NULL) {
this always fails and we never do any of that stuff.
Maybe someone has a clue on how this is meant to work and I can implement that.
Dave.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] ARB draw buffers + texenv program
Just going down the r300g piglit failures and noticed fbo-drawbuffers failed, I've no idea if this passes on Intel hw, but it appears the texenvprogram really needs to understand the draw buffers. The attached patch fixes it here for me on r300g anyone want to test this on Intel with the piglit test before/after? Dave. 0001-texenvprogram-fix-for-ARB_draw_buffers.patch Description: Binary data -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
On Tue, Mar 30, 2010 at 6:26 PM, Nicolai Haehnle nhaeh...@gmail.com wrote: Reply to all this time... On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák mar...@gmail.com wrote: 1) Branching and looping This is the most important one and there are 3 things which need to be done. * Unrolling loops and converting conditionals to multiplications. This is crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases but should be fine for the most common ones. This is kind of a standard in all proprietary drivers supporting shaders 2.0. It would be nice have it work with pure TGSI shaders so that drivers like nvfx can reuse it too and I personally prefer to have this feature first before going on. Would you be able to provide a small example of how to convert the conditionals to multiplications? I understand the basic idea is to mask values based on the result of the conditional, but it would help me to see an example. On IRC, eosie mentioned an alternate technique for emulating conditionals: Save the values of variables that might be affected by the conditional statement. Then, after executing both the if and the else branches, roll back the variables that were affected by the branch that was not supposed to be taken. Would this technique work as well? Well, I am eosie, thanks for the info, it's always cool to be reminded what I've written on IRC. ;) Another idea was to convert TGSI to a SSA form. That would make unrolling branches much easier as the Phi function would basically become a linear interpolation, loops and subroutines with conditional return statements might be trickier. The r300 compiler already uses SSA for its optimization passes so maybe you wouldn't need to mess with TGSI that much... Note that my Git repository already contains an implementation of branch emulation and some additional optimizations, see here: http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glsl Shame on me for abandoning it - I should really get around to make sure it fits in with recent changes and merge it to master. The main problem is that it produces somewhat inefficient code. Adding and improving peephole and similar optimizations should help tremendously. git rebases cleanly onto master, and piglit has -2 for me here texCube-fail glsl-fs-fragcoord - fail Now it might be other things I haven't had to time to investigate, just letting you know that merging it might not a bad plan, Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] llvmpipe autoconf attempt one
I'm not even sure if its fully working, and I've done some nasty stuff in the autoconf.in that probably doesn't belong there, also the dri makefile change to use g++ instead of cc, not sure if there is a cleaner way to do that either. Dave. 0001-llvmpipe-add-initial-autoconf-support.patch Description: Binary data -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium cached bufmgr busy change
On Mon, Mar 8, 2010 at 5:51 PM, Jose Fonseca jfons...@vmware.com wrote:
Dave,
I don't oppose this new method -- it shouldn't be necessary to add fencing
just to use pb_cache --, but this method adds a new way of doing the same
thing.
Does the underlying buffer support PIPE_BUFFER_USAGE_DONT_BLOCK? If so what
about doing:
boolean
pb_cache_is_buffer_compat()
{
void map;
map = pb_map(buf-buffer, PIPE_BUFFER_USAGE_DONT_BLOCK | PIPE_BUFFER);
if (map) {
/* TODO: cache the map value for the first map */
pb_unmap(buf-buffer);
return TRUE;
}
return FALSE;
}
Hi Jose
I've used your scheme but I'm not sure 100% of its correctness since
we might expect
different behaviour from maps that are referenced in flushed command
streams and maps
referenced in the current command stream. I've pushed the r300g bits
that do it correctly and
we haven't seen any regressions.
So my next bit is to bail out after is_busy check to avoid kernel
overheads for checking all
the buffers, but I'm a bit worried it might change behaviour of the
fenced/cached use case,
so I'd appreciate a bit of a review of it.
If this isn't possible I'm tempted to create pb_bufmgr_busy_cached and
do it all there,
I think nouveau could use something similiar.
Dave.
0001-gallium-add-is_busy-flag-to-cached-bufmgr.patch
Description: Binary data
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium cached bufmgr busy change
On Tue, Mar 23, 2010 at 11:41 PM, Luca Barbieri luca.barbi...@gmail.com wrote: Do Radeons have a CP command to write an arbitrary value to some place in memory? If so, you may want to use that to implement userspace-accessible fencing in the obvious way and then use the fenced bufmgr, which would do that with no pipebuffer changes and no kernel calls. Otherwise, maybe change the kernel module to write a fence number in an mmapable place on fence irqs? Why? I don't need any of this. exposing 32-bit numbers to userspace means you have to make sure everyone correctly deals with wrapping, its not worth the effort, and I've no idea why you keep pushing for it, when I've demonstrated I've no need for it at all. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [mesa] r300g dri/st: OpenArena corruptions with mesa-7.8 and master GIT
On Sat, Mar 20, 2010 at 4:18 AM, Sedat Dilek sedat.di...@googlemail.com wrote: Hi Marek - you are nominated for the next DRIgeller (Uri Geller) :-) concerning my problems r300g dri/st with mesa master GIT: THE BAD: commit 68e58a96e80865878e6881dc4d34fcc3ec24eb19 Author: Dave Airlie airl...@redhat.com r300g: rebuild screen/winsys interface Please retest with master, I've just pushed some fixes for piglit regressions hopefully will fix other issues. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!
On Wed, Mar 10, 2010 at 6:47 AM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2010-03-09 at 12:43 -0800, Dave Airlie wrote: On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell kei...@vmware.com wrote: This leaves r300g as the only remaining user of pipe_winsys/u_simple_screen - which means we can rename that code r300_winsys and pull it into that driver... Dave had some code that fixes this, I think. I more or less agreed to stay out of it, but I might take a look if killing u_simple_screen is a priority. It's just a cleanup at this point, no urgency. I'll try and merge the easy bits of my branch to get drop u_simple_screen first. then worry about the cached mgr stuff. Sure, whenever it's convenient. Okay I've pushed the r300g winsys/screen interface update, feel free to kill u_simple_screen with fire. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!
On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell kei...@vmware.com wrote: This leaves r300g as the only remaining user of pipe_winsys/u_simple_screen - which means we can rename that code r300_winsys and pull it into that driver... Dave had some code that fixes this, I think. I more or less agreed to stay out of it, but I might take a look if killing u_simple_screen is a priority. It's just a cleanup at this point, no urgency. I'll try and merge the easy bits of my branch to get drop u_simple_screen first. then worry about the cached mgr stuff. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium cached bufmgr busy change
On Tue, Mar 9, 2010 at 11:30 AM, Luca Barbieri luca.barbi...@gmail.com wrote: The fencing solution isn't near as efficent from what I can see, as it is designed around fences not buffer busy, I'll see if I can give it a try, but I suspect it look and smell like a hack. The problem I see is that while fenced is guaranteed to make at most one fence_signalled query for a busy buffer per allocation, cached could potentially query the busy status of _all_ destroyed buffers for every allocation. The reason of this is that fenced orders the buffers in fence order and stops at the first busy one, only handing them to the lower layer (e.g. cached) once they are no longer busy. If kernel calls are used instead of userspace fencing, the problem probably gets worse. So IMHO it should be much more efficient to use fenced over cached (perhaps with slab between them too). We can do this optimisation with busy as well. As long as you add things to the busy list at the end, and stop testing after the first busy call. At least for a single linear GPU context, which is all I expect this code will ever be handling. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium cached bufmgr busy change
On Sun, Mar 7, 2010 at 9:44 PM, Luca Barbieri luca.barbi...@gmail.com wrote: I think you are supposed to do this using the fenced bufmgr over cached along with a (ideally userspace) fencing mechanism. If you can implement pb_busy, you should be able to implement fence_signalled in exactly the same way (making the fence handle a pointer to buffers should work for this purpose, if standalone fences are hard to do). The fenced bufmgr will only pass destruction requests to the wrapped bufmgr once the fences are signalled. It just seemed a bit heavyweight, I don't want userspace fences, so why do I have to jump though abstraction hoops? The fencing solution isn't near as efficent from what I can see, as it is designed around fences not buffer busy, I'll see if I can give it a try, but I suspect it look and smell like a hack. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [rfc] to SpanRenderStart to avoid texture mapping overheads
So in classic drivers we can hit swrast fallbacks for things like ReadPixels where we know we aren't going to have to want to touch textures at all. This would be useful for the r300 driver where Maciej is working on texture tiling will allow us to avoid the untiling overheads that mapping textures requires for most sw fallbacks. There may be other operations where we can do this also. For render to texture scenarios the driver should still map the textures via the FBOs anyways. Dave. swrast_start_rfc.patch Description: Binary data -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium cached bufmgr busy change
I've been playing with strategies to get r300 buffer management a bit more efficient, I've reworked the r300g screen/winsys and create a pb_bufmgr compliant buffer class, and stacked the cached buffer manager on top of it. Now I've hit a problem in that we expose buffer busy state, but the cached bufmgr doesn't know to check if the buffer is busy before reusing it. The attached patch adds a query for buffer busy to pb_bufmgr.h. I've wondered if I can do this with some hacked up fences but it seems like a lot more work for not much gain. Dave. cached-bufmgr-busy.patch Description: Binary data -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium software fallback/draw command failure
On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt b...@zhasha.com wrote: On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote: Hi, I am a bit puzzled, how a pipe driver should handle draw callback failure ? On radeon (pretty sure nouveau or intel hit the same issue) we can only know when one of the draw_* context callback is call if we can do the rendering or not. The failure here is dictated by memory constraint, ie if user bind big texture, big vbo ... we might not have enough GPU address space to bind all the desired object (even for drawing a single triangle) ? What should we do ? None of the draw callback can return a value ? Maybe for a GL stack tracker we should report GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line is i think pipe driver are missing something here. Any idea ? Thought ? Is there already a plan to address that ? :) Cheers, Jerome I think a vital point you're missing is: do we even care? If rendering fails because we simply can't render any more, do we even want to fall back? I can see a point in having a cap on how large a buffer can be rendered but apart from that, I'm not sure there even is a problem. Welcome to GL. If I have a 32MB graphics card, and I advertise a maximum texture size of 4096x4096 + cubemapping + 3D textures, there is no nice way for the app to get a clue about what it can legally ask me to do. Old DRI drivers used to either use texmem which would try and scale the limits etc to what it could legally fit in the memory available, or with bufmgr drivers they would check against a limit from the kernel, and in both cases sw fallback if necessary. Gallium seemingly can't do this, maybe its okay to ignore it but it wasn't an option when we did the old DRI drivers. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa removals
I'm actually in the process of gathering hardware to revive gamma (or rewrite its stack all together). So I don't know whether it should be removed or not. Certainly the mesa component of the stack won't be touched until I get a memory manager working. I suspect any attempt at reviviing it will need a 3D driver re-write anyways. Since it heavily relies on the dma scheme it used. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): gallium: fix more missing includes from various places
On Wed, 2010-02-03 at 18:16 -0700, Brian Paul wrote: Dave Airlie wrote: Module: Mesa Branch: master Commit: 3584a44270a7f3a04e187bd79b5373314514d383 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=3584a44270a7f3a04e187bd79b5373314514d383 Author: Dave Airlie airl...@redhat.com Date: Thu Feb 4 10:52:43 2010 +1000 gallium: fix more missing includes from various places nouveau/ dri st / vmware --- src/gallium/drivers/nouveau/nouveau_screen.c |2 ++ src/gallium/drivers/nv04/nv04_context.h|1 + src/gallium/state_trackers/dri/dri_drawable.c |1 + src/gallium/state_trackers/dri/dri_screen.c|2 ++ src/gallium/state_trackers/xorg/xorg_tracker.h |2 ++ src/gallium/winsys/drm/vmware/core/vmw_buffer.h|2 +- .../winsys/drm/vmware/core/vmw_screen_dri.c|1 + src/gallium/winsys/drm/vmware/core/vmw_surface.h |2 +- 8 files changed, 11 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c b/src/gallium/drivers/nouveau/nouveau_screen.c index 1ad539d..156cb2d 100644 --- a/src/gallium/drivers/nouveau/nouveau_screen.c +++ b/src/gallium/drivers/nouveau/nouveau_screen.c @@ -3,7 +3,9 @@ #include pipe/p_state.h #include util/u_memory.h +#include util/u_inlines.h The usual convention for these gallium #includes is to use quotes, not angle brackets. Oops I just conformed to what was around me, maybe nouveau guys can fix them all. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium: ARB_half_float_vertex
Since the whole patent mess can't apply to floating vertices here are some
gallium patches.
First adds a new screen interface for is_vertex_format_supported and also
we seems to have some GPUs with a single R16 and some with R16X16 so allow
or this.
second is just i965g patch.
If these are okay, I can look at softpipe support via translate. Not sure
exposing this extension always and using translate always makes sense as
it defeats the purpose of this extension.
Dave.
From b8ea9848a61fe2469ae87bdc8ba44ea40b25b8ef Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@linux.ie
Date: Tue, 26 Jan 2010 19:12:36 +1000
Subject: [PATCH 2/2] i965g: add support for ARB_half_float_vertex
This adds the format bits to the 965g vertex emission. Untested
due to 965g appearing to smash my GPU currently.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/i965/brw_draw_upload.c |9 +
src/gallium/drivers/i965/brw_screen.c | 21 +
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/i965/brw_draw_upload.c b/src/gallium/drivers/i965/brw_draw_upload.c
index a27da5f..4ca75e0 100644
--- a/src/gallium/drivers/i965/brw_draw_upload.c
+++ b/src/gallium/drivers/i965/brw_draw_upload.c
@@ -170,6 +170,15 @@ static unsigned brw_translate_surface_format( unsigned id )
case PIPE_FORMAT_R8G8B8A8_SSCALED:
return BRW_SURFACEFORMAT_R8G8B8A8_SSCALED;
+ case PIPE_FORMAT_R16_FLOAT:
+ return BRW_SURFACEFORMAT_R16_FLOAT;
+ case PIPE_FORMAT_R16G16_FLOAT:
+ return BRW_SURFACEFORMAT_R16G16_FLOAT;
+ case PIPE_FORMAT_R16G16B16X16_FLOAT:
+ return BRW_SURFACEFORMAT_R16G16B16X16_FLOAT;
+ case PIPE_FORMAT_R16G16B16A16_FLOAT:
+ return BRW_SURFACEFORMAT_R16G16B16A16_FLOAT;
+
default:
assert(0);
return 0;
diff --git a/src/gallium/drivers/i965/brw_screen.c b/src/gallium/drivers/i965/brw_screen.c
index 0ecacac..d3505cb 100644
--- a/src/gallium/drivers/i965/brw_screen.c
+++ b/src/gallium/drivers/i965/brw_screen.c
@@ -203,6 +203,26 @@ brw_get_paramf(struct pipe_screen *screen, int param)
}
static boolean
+brw_is_vertex_format_supported(struct pipe_screen *screen,
+ enum pipe_format format)
+{
+ static const GLuint pipe_format_extra[] = {
+ PIPE_FORMAT_R16_FLOAT,
+ PIPE_FORMAT_R16G16_FLOAT,
+ PIPE_FORMAT_R16G16B16X16_FLOAT,
+ PIPE_FORMAT_R16G16B16A16_FLOAT,
+ PIPE_FORMAT_NONE,
+ };
+ int i;
+
+ for (i = 0; pipe_format_extra[i] != PIPE_FORMAT_NONE; i++) {
+ if (pipe_format_extra[i] == format)
+ return TRUE;
+ }
+ return FALSE;
+}
+
+static boolean
brw_is_format_supported(struct pipe_screen *screen,
enum pipe_format format,
enum pipe_texture_target target,
@@ -387,6 +407,7 @@ brw_create_screen(struct brw_winsys_screen *sws, uint pci_id)
bscreen-base.get_vendor = brw_get_vendor;
bscreen-base.get_param = brw_get_param;
bscreen-base.get_paramf = brw_get_paramf;
+ bscreen-base.is_vertex_format_supported = brw_is_vertex_format_supported;
bscreen-base.is_format_supported = brw_is_format_supported;
bscreen-base.fence_reference = brw_fence_reference;
bscreen-base.fence_signalled = brw_fence_signalled;
--
1.6.5.2
From 0b0624f0530c9825f72bf1e1af1993d2749c5ce5 Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@linux.ie
Date: Tue, 26 Jan 2010 19:10:06 +1000
Subject: [PATCH 1/2] gallium: add support for ARB_half_float_vertex
This adds a new screen interface, is_vertex_format_supported which we
used to query for the different half float vertex types, from Luca's reading
of NV30 docs it appears we need an R16X16 as well as R16.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/include/pipe/p_format.h|6 ++
src/gallium/include/pipe/p_screen.h|9 +
src/mesa/state_tracker/st_draw.c | 14 +-
src/mesa/state_tracker/st_draw.h |2 ++
src/mesa/state_tracker/st_extensions.c | 13 +
5 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/src/gallium/include/pipe/p_format.h b/src/gallium/include/pipe/p_format.h
index 6bfff1c..d3af65a 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -166,6 +166,12 @@ enum pipe_format {
PIPE_FORMAT_DXT3_SRGBA= 108,
PIPE_FORMAT_DXT5_SRGBA= 109,
+ /* based on DX formats + R16X16 for nv30 */
+ PIPE_FORMAT_R16_FLOAT = 110,
+ PIPE_FORMAT_R16X16_FLOAT = 111,
+ PIPE_FORMAT_R16G16_FLOAT = 112,
+ PIPE_FORMAT_R16G16B16X16_FLOAT= 113,
+ PIPE_FORMAT_R16G16B16A16_FLOAT= 114,
PIPE_FORMAT_COUNT
};
diff --git a/src/gallium/include/pipe/p_screen.h b/src/gallium/include/pipe/p_screen.h
index b8e001a..887d527 100644
--- a/src/gallium/include/pipe/p_screen.h
+++ b/src/gallium/include/pipe/p_screen.h
@@ -87,6 +87,15 @@ struct pipe_screen {
float (*get_paramf
Re: [Mesa3d-dev] gallium docs
Another thing that bother me, is that gallium community is very small but worse thing is that some of people who are working on gallium are very hard to approach, even arrogant. This is certainly not way how to build successful society, for sure. It looks like that they consider themselves as that they have some mission and stuffs like community are not important at all. Documentation, as an example, fits perfectly into my story. There is no successful community if there aren't good documentation. I really do not know how do you imagine to develop any large-scale project if you do not develop documentation concurrently with code!? Documentation is at least important as source code is (read Donald Knuth!). I don't think any of this is true, I'm not sure what you think will help you gain entry to the community, the main entry level to any open source community is Just Do It. It would be nice to be hand held into the community but looking at recent developer numbers the community has expanded quite well without everything you claim is required to build a community. It is always nice to have more documentation but its a simple return on investment problem and in fact I think it would be interesting for someone joining the community to attempt to write docs on how to enter the community and how they learned things. In fact most of my interaction with you seems based around you getting a job from some company, this is not how you enter a community and I've felt you've at least to me come across with all the wrong reasons for wanting to do this. To work on 3D drivers and Gallium, the main entry point I think nearly everyone who works on the codebase shares is fixing bugs on a system they have access to. So if you have Intel hw, trying to pick up i965g driver and fixing the bugs in it, or similiar for radeon/nouveau with thier gallium drivers. Most of the drivers also maintain TODO lists. Also there are Mesa GL3.0 todo lists for gallium, I recently added GL_ARB_half_float_vertex that was a pretty simple entry level, I haven't done the gallium suppor tfor this yet. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] ARB_half_float_vertex support branch
Hey, Stuck at home today minding sick (on the mend now baby) with only my 965 laptop, and someone mentioned this morning on irc that we don't do ARB_half_float_vertex, and after reading that patent stuff doesn't apply to this by my reckoning it didn't seem that hard to throw together. I found a BSD licensed half-float array convertor, wrote a really simple test app, and added the glapi, mesa core and 965 support. I'm sure it needs work and there is a good chance I won't get back to figuring out whats missing from it, but if some kind soul could review it and let me know what I missed, I might find some time to fix it up. I think at least r500/r600 can support this. if anyone wants I can send the patches to the list. Dave. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium: add overlapping blit support to u_blitter
This makes the r300g + X.org state tracker work a bit better, I can
start X + xterm + metacity and drag a window around now at least.
A full gnome session seems to have other issuess.
Dave.From b8f1d1cf45aa23c74b2d150058506a6a27737d25 Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@redhat.com
Date: Thu, 7 Jan 2010 11:45:48 +1000
Subject: [PATCH] gallium: u_blitter add overlapping blit support.
the xorg state tracker really wants the driver to handle overlapping
blits, and r300 uses u_blitter for blits. This patch adds overlapping
blit support via a temporary surface when its required.
---
src/gallium/auxiliary/util/u_blitter.c | 158 +---
1 files changed, 124 insertions(+), 34 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blitter.c b/src/gallium/auxiliary/util/u_blitter.c
index 1f794d3..58f0b6d 100644
--- a/src/gallium/auxiliary/util/u_blitter.c
+++ b/src/gallium/auxiliary/util/u_blitter.c
@@ -560,45 +560,30 @@ void util_blitter_clear(struct blitter_context *blitter,
blitter_restore_CSOs(ctx);
}
-void util_blitter_copy(struct blitter_context *blitter,
- struct pipe_surface *dst,
- unsigned dstx, unsigned dsty,
- struct pipe_surface *src,
- unsigned srcx, unsigned srcy,
- unsigned width, unsigned height,
- boolean ignore_stencil)
+static boolean
+is_overlap(int sx1, int sx2, int sy1, int sy2, int dx1, int dx2, int dy1, int dy2)
+{
+if (((sx1 = dx1) (sx1 = dx2) (sy1 = dy1) (sy1 = dy2)) || /* TL x1, y1 */
+ ((sx2 = dx1) (sx2 = dx2) (sy1 = dy1) (sy1 = dy2)) || /* TR x2, y1 */
+ ((sx1 = dx1) (sx1 = dx2) (sy2 = dy1) (sy2 = dy2)) || /* BL x1, y2 */
+ ((sx2 = dx1) (sx2 = dx2) (sy2 = dy1) (sy2 = dy2))) /* BR x2, y2 */
+ return TRUE;
+else
+ return FALSE;
+}
+
+static void util_blitter_do_copy(struct blitter_context *blitter,
+ struct pipe_surface *dst,
+ unsigned dstx, unsigned dsty,
+ struct pipe_surface *src,
+ unsigned srcx, unsigned srcy,
+ unsigned width, unsigned height,
+ boolean is_depth)
{
struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
struct pipe_context *pipe = ctx-pipe;
- struct pipe_screen *screen = pipe-screen;
struct pipe_framebuffer_state fb_state;
- boolean is_stencil, is_depth;
- unsigned dst_tex_usage;
-
- /* give up if textures are not set */
- assert(dst-texture src-texture);
- if (!dst-texture || !src-texture)
- return;
-
- is_depth = util_format_get_component_bits(src-format, UTIL_FORMAT_COLORSPACE_ZS, 0) != 0;
- is_stencil = util_format_get_component_bits(src-format, UTIL_FORMAT_COLORSPACE_ZS, 1) != 0;
- dst_tex_usage = is_depth || is_stencil ? PIPE_TEXTURE_USAGE_DEPTH_STENCIL :
-PIPE_TEXTURE_USAGE_RENDER_TARGET;
-
- /* check if we can sample from and render to the surfaces */
- /* (assuming copying a stencil buffer is not possible) */
- if ((!ignore_stencil is_stencil) ||
- !screen-is_format_supported(screen, dst-format, dst-texture-target,
-dst_tex_usage, 0) ||
- !screen-is_format_supported(screen, src-format, src-texture-target,
-PIPE_TEXTURE_USAGE_SAMPLER, 0)) {
- util_surface_copy(pipe, FALSE, dst, dstx, dsty, src, srcx, srcy,
-width, height);
- return;
- }
- /* check whether the states are properly saved */
- blitter_check_saved_CSOs(ctx);
assert(blitter-saved_fb_state.nr_cbufs != ~0);
assert(blitter-saved_num_textures != ~0);
assert(blitter-saved_num_sampler_states != ~0);
@@ -656,6 +641,111 @@ void util_blitter_copy(struct blitter_context *blitter,
blitter_set_rectangle(ctx, dstx, dsty, dstx+width, dsty+height, 0);
blitter_draw_quad(ctx);
+
+}
+
+static void util_blitter_overlap_copy(struct blitter_context *blitter,
+ struct pipe_surface *dst,
+ unsigned dstx, unsigned dsty,
+ struct pipe_surface *src,
+ unsigned srcx, unsigned srcy,
+ unsigned width, unsigned height)
+{
+ struct blitter_context_priv *ctx = (struct blitter_context_priv*)blitter;
+ struct pipe_context *pipe = ctx-pipe;
+ struct pipe_screen *screen = pipe-screen;
+
+ struct pipe_texture texTemp;
+ struct pipe_texture *texture;
+ struct pipe_surface *tex_surf;
+ uint level;
+
+ /* check whether the states are properly saved */
+ blitter_check_saved_CSOs(ctx);
+
+ memset(texTemp, 0, sizeof(texTemp));
+ texTemp.target = PIPE_TEXTURE_2D;
+ texTemp.format = dst-texture-format; /* XXX verify supported by driver! */
+ texTemp.last_level = 0;
+ texTemp.width0 = width;
+ texTemp.height0 = height;
+ texTemp.depth0 = 1;
+
+ texture = screen-texture_create(screen, texTemp);
+ if (!texture)
+ return;
+
+ tex_surf = screen-get_tex_surface(screen, texture, 0
[Mesa3d-dev] libdrm_radeon API change
So I've changed libdrm_radeon API upsteram, I'd like to fixup Mesa 7.6 + 7.7 branches to request the new API using a similiar patch I just committed from Fabio. Reasoning is: a) libdrm declares the ABI as unstable, so any distro shipping it already has agreed to burden the hassle. if they ship the old libdrm_Radeon, they'll just need to ship 2.4.17 libdrm. b) if a distro has never shipped a libdrm_radeon, mesa ships all the code necessary to do the non-kms/dri2 paths without it. So they won't be affected. I'll do this tomorrow if nobody objects, the API changes are fairly pickable. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] flushing vertices in radeon swtcl
Hey all,
So in mesa for swtcl cases we emit vertices to DMA, and set a driver
internal dma.flush hook, we also set
ctx-Driver.NeedFlush |= FLUSH_STORED_VERTICES;
The driver has its FlushVertices pointed at the vbo_exec_FlushVertices
call.
I'm not sure when this ever worked but I assume it did at one stage in
r100 driver since I haven't really changed this code flow, I'm
contemplating doing something like the below but maybe someone can
say when this all got broken.
any insights? Keith?
Dave.
Dave.
diff --git a/src/mesa/drivers/dri/radeon/radeon_context.c
b/src/mesa/drivers/dri/radeon/radeon_context.c
index 8f4485a..d103ac5 100644
--- a/src/mesa/drivers/dri/radeon/radeon_context.c
+++ b/src/mesa/drivers/dri/radeon/radeon_context.c
@@ -204,6 +204,14 @@ static void r100_init_vtbl(radeonContextPtr radeon)
radeon-vtbl.emit_query_finish = r100_emit_query_finish;
}
+static void radeon_flush_vertices(GLcontext *ctx, GLuint flags)
+{
+ r100ContextPtr rmesa = R100_CONTEXT(ctx);
+ if (rmesa-radeon.dma.flush)
+ rmesa-radeon.dma.flush(ctx);
+ vbo_exec_FlushVertices(ctx, flags);
+}
+
/* Create the device specific context.
*/
GLboolean
@@ -329,6 +337,7 @@ r100CreateContext( const __GLcontextModes *glVisual,
_swsetup_CreateContext( ctx );
_ae_create_context( ctx );
+ ctx-Driver.FlushVertices = radeon_flush_vertices;
/* Install the customized pipeline:
*/
_tnl_destroy_pipeline( ctx );
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] flushing vertices in radeon swtcl
So in mesa for swtcl cases we emit vertices to DMA, and set a driver internal dma.flush hook, we also set ctx-Driver.NeedFlush |= FLUSH_STORED_VERTICES; The driver has its FlushVertices pointed at the vbo_exec_FlushVertices call. I'm not sure when this ever worked but I assume it did at one stage in r100 driver since I haven't really changed this code flow, I'm contemplating doing something like the below but maybe someone can say when this all got broken. any insights? Keith? Hmm, it would seem like you'd need this if: a) you have a hw vertex buffer that you're incrementally extending as new vertices arrive b) you are delaying emitting the draw packet until you know how many vertices you put in that buffer, and c) you don't have any other mechanism to ensure that draw packet doesn't attempt to span hw statechanges. You wrote the original ;-), its the r100 swtcl code. I've just been pushing it around the place since, but yes, a, b, c all seem to be true. IE. if you're optimistically trying to combine incoming primitives into single draw packets, and don't have code to flush that in response to state-changes, then this patch makes sense. If the above doesn't describe your situation, I don't think you want this. However, even if it does, note that you'd be better off trying to figure out when a *real* hardware statechange is about to happen before tying off the old draw packet, as Driver.FlushVertices is going to get called on every putative mesa statechange, many of which won't result in hardware statechanges. In fact, thinking about it, if you flush on every call to this function, you basically defeat the optimization it seems you're trying to implement, because the incoming vertices you're trying to combine will almost always have a mesa statechange between them -- there's no other reason mesa would break them up, and Mesa already tries to combine incoming application draws that aren't separated by statechanges. So if you do this, really you'd be just as well served with an eager emit of the draw packet forget about trying to be lazy. That probably makes more sense then, I should push the draw packet at a better place, what happens at the moment, is I get a state change without getting the flush, and emit a bunch of texture state that doesn't match the vertices I've already stuck in the vertex buffer, with the new kernel checker it detects the illegal state. Dave. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r300: piglit test results on Mesa 7.6 branch
Am Monday 21 September 2009 19:45:15 schrieb Maciej Cencora: Hi, I've got a fix for vbo-map-remap, fdo14575 and fdo22540 sitting in my local tree, (the code hasn't been aligned after Brian's 92033a9516942d7272ce4bf36ecd422009bbaf60 and 822c7964819ca1fcc270880d4ca8b patches. texture_srgb test should probably have some error margin. I can't tell much about FBOs - maybe Dave can check it. I will take a closer look at OQ bugs. The FBO failures were depth texture related and I didn't get a chance to figure out what was causing it, I've a funny feeling depth texture format on r500 might be wrong. Dave. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (mesa_7_6_branch): i965: do a flush in clear, fix openarena render issue,
Is this still being tracked down? we should probably revert the hack if nobody is actually going to look for the proper fix. I have replaced the intelFlush to a intel_batchbuffer_flush, then benchmark it with ut2004 demo. Found almost no regression. Its not about a regresssion there is a bug, you are hiding it not fixing it, this bug could affect us later somehow, better to deal with it now. we should not need to flush before a clear it shoud be just more state in the command stream. Dave. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (mesa_7_6_branch): i965: do a flush in clear, fix openarena render issue,
In general, adding flush() calls is not the correct way to fix bugs (and can impact performance). This flush is probably hiding the true cause of the bug. Unfortunately, I don't know what that would be. I don't know exactly the reason. It seems that some rendering is delayed to the next frame. So I add flush here to make them visible in the current frame. Is this still being tracked down? we should probably revert the hack if nobody is actually going to look for the proper fix. Dave. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.6 branch coming
Funny you should mention whitespace. I've been looking at the radeon code a bit lately. What a mess. Within a single source file I've seen 3 different levels of indentation (3/4 space and 8-space tabs). I'd be happy to see the whole thing run through 'indent'. I've been holding off, its the problem with merging code from 3 drivers with different white space into one set of common code, you get bits of the style of all 3 drivers. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.6 branch coming
I've been holding off, its the problem with merging code from 3 drivers with different white space into one set of common code, you get bits of the style of all 3 drivers. Oh and the other problem is indent doesn't understand typedefs properly, so anywhere you have void func(radeon_t *arg) you end up with void func(radeon_t * arg). So I guess I'll have to do it manually which is also why I've been lazy. Dave. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] cairo-dock insanity what to do?
So I tried to run cairo-dock and ran into some really dumb insanity in it which I'm sure isn't GL compliant but I'm not sure how I should tell it to foad. So it calls gtk init and this opens a display connection, it then calls XOpenDisplay in another place, it createa context on the gtk inited connection, then creates another context on the XOpenDisplay connection passing the gtk context as a share. Now we don't end up with the same screen as they were inited on separate display connections, and thusly the contexts shared buffer objects from different kernel memory managers which blows up. So is this legal? I suspect we should be returning BadMatch to the glXCreateContext. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] radeon-rewrite merged to master
I think we've gone as far as we can with radeon-rewrite, it was starting to outshine master in a few areas mainly thanks to Maciej (osiris) work, We've lost support for a couple of things (hyperz/texture tiling) temporarily but they will return once we can figure out how they work again :) Hopefully TTM/KMS work is in the kernel staging area soon, and we can move radeon support onto a new place :) any major regressions on r100/r200 would be useful to know as we don't have as many people focusing on those. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] More radeon-rewrite patches
Dnia sobota, 6 czerwca 2009 o 17:09:28 Michel Dänzer napisał(a): On Sat, 2009-06-06 at 13:27 +0200, Maciej Cencora wrote: - rebased Michel Daenzer's patch. Please preserve the author string of my patch. I've just added Signed-off-by with my name, but you're still the patch author. I've pushed all these and fixed Michel's original vmware email address on his one. Dave Airlie is going to merge it soon (IIRC he said something about this weekend or next week). Does it perform a lot worse (compared to master branch) even without this round of patches? I'll probably do some more comparisons on some tcl and some non-tcl hw this week, and merge it if nothing major stands out. on my rs690 at least, gears and ipers both get an increase with radeon-rewrite. Dave.-- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] More radeon-rewrite patches
Does it perform a lot worse (compared to master branch) even without this round of patches? I'll probably do some more comparisons on some tcl and some non-tcl hw this week, and merge it if nothing major stands out. on my rs690 at least, gears and ipers both get an increase with radeon-rewrite. With current radeon-rewrite, OA hangs the GPU on DRI1 with the anholt demo from the DRI benchmarking page. not 100% sure whats going on yet, or when it started. Dave. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] DMA buffer management + KMS
OK, with that hint the convolutions became a little bit more clear. The
exact problem is:
drm_buffer_object_create() is called with flags=DRM_BO_FLAG_MEM_TT
(DRM_BO_FLAG_CACHED is not included because this is a AGP system)
bo-mem.flags = BO_FLAG_MEM_LOCAL | ...
bo-mem.proposed_flags = BO_FLAG_MEM_TT | ...
drm_bo_do_validate()
drm_buffer_object_validate(..., move_buffer=TRUE)
drm_bo_move_buffer()
drm_bo_add_ttm()
drm_ttm_create(page_flags=DRM_BO_FLAG_WRITE)
drm_ttm_bind()
drm_ttm_set_caching(noncached=DRM_TTM_PAGE_UNCACHED,
alloc_cached=FALSE)
drm_ttm_populate(cached=FALSE)
Allocates uncached memory from pool
proceeds to mark memory uncached, expensively
The problem was introduced with:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=37136c81b28e45f30c8d45d212315c0b4ce6c6b0
(I'm unclear what the upstream referred to in the commit message is, maybe
the original had a more informative commit message...)
From the new ttm code, just quick response is the original code did what
you say below, only setting caching before populating, however that
caused the black bar lines on migration.
I didn't get a chance to solve both speed and correctness so just got the
black bars fixed despite it slowing down the GART buffer allocs.
I'd like to fix this at some point, but I never got to understand wtf the
blackbars were coming from, apart from it being something to do with
evicted buffers.
Dave.
Prior to that set_caching would be called with no pages allocated, which is
a no-op,and then the pages allocated uncached. With that change, the above
problem occurs.
[ I was thinking I hadn't seen this pathology in profiling with a slightly
older kernel... ]
It looks quite plausible that reversing the order of:
if ((ttm-page_flags DRM_TTM_PAGE_UNCACHED) == noncached)
return 0;
{
ret = drm_ttm_populate(ttm, alloc_cached);
if (ret != 0)
return ret;
}
So that we do the shortcut if we allocate new memory of the right
cachedness is the right thing to do.
But I'd be a lot more confident of that if I had any understanding of
the commit above.
Anyway i think the plan for newttm is to use such page allocator so
we can avoid changing cache status of page on every allocation, also
we would like to avoid zeroing page more than necessary for this we
need that the userspace keep the buffer around.
Hmm, isn't the problem with that approach knowing when the kernel is
done with buffers so they are ready for reuse? You'd need some way to
query the kernel to find out what command buffers have completed.
So in the end the call to drm_ttm_set_cahing (or equivalent in newttm)
should happen only once at buffer creation.
Btw the limit on radeon for vertex buffer is quite high:
max number of vertices * max stride = 65536 * (128 * 4) = 32M but i
think it's unlikely to have a stride 128 dwords, common case would
around 32 dwords i think.
Not quite sure what you are referring to - the DMA buffer seems to be
sized assuming a stride of 4 dwords - It's just 16 * 65536.
[ Even 32 dwords seems very high to me - for example the most
complicated format supported by glInterleavedArrays - GL_T4F_C4F_N3F_V4F
- is just 15 dwords. ]
- Owen
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, Big Spaceship. http://www.creativitycat.com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, Big Spaceship. http://www.creativitycat.com
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] DMA buffer management + KMS
I'd like to fix this at some point, but I never got to understand wtf the blackbars were coming from, apart from it being something to do with evicted buffers. Aha! So, two characteristics of the black bars I remember: - They were 16-pixel (64-byte) horizontal stripes, 64-byte aligned. That is, cache lines. - They were black. That is, the cache-line contents for a newly zeroed page Note also that the function to add pages to the page free lists - drm_add_pages_locked() - calls set_memory_wc(), but it doesn't do the other thing that drm_ttm_set_caching() does: call drm_clflush_pages() Ah that could have been it. care to give it a hack, I'm on hols for another week or so. Dave. So, I believe the black bar problem was simply that when migrating a buffer from vram to newly allocated system memory pages, cached data written to those pages by the CPU wasn't flushed before blitting the migrated data. If that theory makes sense, then 37136c81 is pretty much entirely extraneous - it fixes the black bars by defeating the point of the free list of uncached pages and doing the work of drm_ttm_set_caching() on every page pulled out of the free list. - Owen -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [rfc patch] dri drawable ref counting
valgrind was showing a race between the drawable getting destroyed
by the X resource freeing code, and the context getting destroyed
later and freeing the drawable.
However I've no idea if some other combination of things could cause
this code to leak.
Any one else have any ideas?
---
src/mesa/drivers/dri/common/dri_util.c | 32
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index 38c2e7b..0ec4adc 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -37,6 +37,9 @@
typedef GLboolean ( * PFNGLXGETMSCRATEOMLPROC) (__DRIdrawable *drawable,
int32_t *numerator, int32_t *denominator);
#endif
+static void dri_get_drawable(__DRIdrawable *pdp);
+static void dri_put_drawable(__DRIdrawable *pdp);
+
/**
* This is just a token extension used to signal that the driver
* supports setting a read drawable.
@@ -127,7 +130,7 @@ static int driUnbindContext(__DRIcontext *pcp)
return GL_FALSE;
}
-pdp-refcount--;
+dri_put_drawable(pdp);
if (prp != pdp) {
if (prp-refcount == 0) {
@@ -135,7 +138,7 @@ static int driUnbindContext(__DRIcontext *pcp)
return GL_FALSE;
}
- prp-refcount--;
+ dri_put_drawable(prp);
}
@@ -170,10 +173,10 @@ static int driBindContext(__DRIcontext *pcp,
pcp-driReadablePriv = prp;
if (pdp) {
pdp-driContextPriv = pcp;
- pdp-refcount++;
+ dri_get_drawable(pdp);
}
if ( prp pdp != prp ) {
- prp-refcount++;
+ dri_get_drawable(prp);
}
}
@@ -430,7 +433,7 @@ driCreateNewDrawable(__DRIscreen *psp, const __DRIconfig
*config,
pdp-loaderPrivate = data;
pdp-hHWDrawable = hwDrawable;
-pdp-refcount = 0;
+pdp-refcount = 1;
pdp-pStamp = NULL;
pdp-lastStamp = 0;
pdp-index = 0;
@@ -483,12 +486,19 @@ dri2CreateNewDrawable(__DRIscreen *screen,
return pdraw;
}
-
-static void
-driDestroyDrawable(__DRIdrawable *pdp)
+static void dri_get_drawable(__DRIdrawable *pdp)
+{
+pdp-refcount++;
+}
+
+static void dri_put_drawable(__DRIdrawable *pdp)
{
__DRIscreenPrivate *psp;
+pdp-refcount--;
+if (pdp-refcount)
+ return;
+
if (pdp) {
psp = pdp-driScreenPriv;
(*psp-DriverAPI.DestroyBuffer)(pdp);
@@ -504,6 +514,12 @@ driDestroyDrawable(__DRIdrawable *pdp)
}
}
+static void
+driDestroyDrawable(__DRIdrawable *pdp)
+{
+dri_put_drawable(pdp);
+}
+
/*...@}*/
--
1.6.2.2
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 7.5 plans
I'm looking at making the 7.5 release on Friday. The main objective of this development release will be an initial milestone / roll-out of the Gallium bits. Then, I'd like to quickly create the Mesa 7.6 branch for stabilization. git/master will then again be open to any/all development. If this is too soon for anyone, let me know so we can work something out. I also think a 7.4.1 release will happen soon. 7.4 had a bit of a regression in the glTexParameter() code which Roland found/fixed. Plus there's some other useful bug fixes on the 7.4 branch. I'd really like to merge the radeon-rewrite branch sooner rather than later, however I still think DRI2 needs some more work and I'd hate to have us release something where the interfaces haven't settled, I'd at least like to see front buffer rendering working so we run test suites on it. Dave. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] piglit texture test issue
Hey, Just wondering what should be done, but gen-teximage.c and gen-texsubimage.c at lesat both do glutSwapBuffers glFlush glReadPixels. Now glReadPixels defaults to reading from the backbuffer, and in theory after a swapbuffers the contents of the backbuffer are undefined. I'm sure the fix is to glReadPixels before the swapbuffers or glReadBuffer(GL_FRONT) before it. Since DRI2 + Front buffer rendering is hosed the second option isn't so pretty. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] FBOs and texture formats
Hey, So I've been playing with radeon FBOs and have run into a problem with how to allow apps to get an FBOs that isn't swrast fallback :-) radeons can by default render to ARGB, ARGB, RGB565 mostly, now in this case when the app asks for a texture format of GL_RGBA, GL_UNSIGNED_BYTE, we return by default a texture format, of _mesa_texformat_rgba_rev This allows us to do memcpy texture uploads in theory, however when it comes time to render to that texture, I have to go hit a sw fallback which sucks badly. I see my options as a) apps are smart, ignore problem and move on. b) pick FBO friendly texture formats by default at the expense of textures c) magically change the texture format when I realise something is rendering to it (is this possible any ideas?) d) at least for r300, hack up the fragment shader to swizzle the outputs though I think for dest blending this might not work like I think it would. hopes nobody tells me the FBO spec covers this and I'm lazy :) Dave. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.
textures like spans? The intel driver de-tiles in the software span accessing functions. Or is there something I'm missing here? Do textures go through some other path? It detiles buffer access via spans, textures don't go via spans from what I can see, the texstore code seems to operate direct on the buffers. Intel doesn't do texture tiling from what I know yet. Dave. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.
Hi all, So I had to drop texture tiling when I did the radeon-rewrite but I'd like to bring them back. Now with traditional drivers, we have the mesa copy of the texture and the card copy, and we usually texture from VRAM only, so we can upload to VRAM and tile on the way, and if we hit a sw fallback we just use the textures from the mesa fallback. In the bufmgr world in theory we don't keep two copies of textures around, and on radeons we can at least enable texture tiling on GART textures. So if I store the texture tiled for hw use, we don't have anything like span access to textures from what I can see for sw use. If the texture was in VRAM, in theory for sw use we could use a surface, however it leave tiled in GART busted. I'm just wondering if anyone has already tackled this in any driver, and how this could work best. Does Gallium provide surface accessors for textures like spans? I'm sort of thinking I keep two buffers objects, one sw only and one for hw to use and use the GPU to blit between them when updates are needed. Dave. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa regression
Hi, f9ce417aaf14c00e72e92307b910de5dbed1bb6d causes regression in some 3d apps on my rs690 (non tcl hw). glxgears: vbo/vbo_exec_api.c:751: vbo_exec_BeginVertices: Assertion `exec- ctx-Driver.NeedFlush == 0' failed. texfilt: vbo/vbo_exec_api.c:788: vbo_exec_FlushVertices: Assertion `exec-ctx- Driver.NeedFlush 0x2' failed. Reverting this patch fixes the problem. Keith any info? you broke r300 swtcl, but I'm not sure why. Dave. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
Gallium3D currently builds on Linux userland (gcc), Windows user-space (MSVC, MinGW, and MinGW cross-compilers) and Windows kernel-space (MSVC only unfortunately). Mesa3D/Gallium3D scons build system supports all those combinations, *today*. Jose it supports building, I think Donnie's point is that its impossible to package something that uses scons, so makes it useless to people who downstream consume Mesa instead of developers doing builds. Dave. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] radeon-rewrite branch merging.
Compressed textures also seem to be broken, since they'll raise a FPE: Program received signal SIGFPE, Arithmetic exception. [Switching to Thread -1480239424 (LWP 11180)] 0x9c80da1d in radeon_miptree_create (rmesa=0x9499c48, t=0x9909e80, target=3553, firstLevel=0, lastLevel=10, width0=1024, height0=1024, depth0=1, bpp=0, tilebits=0, compressed=38) at radeon_mipmap_tree.c:79 79 align = 32 / mt-bpp; bpp is derived initially from TexelBytes, which is always 0 for compressed textures. I'm probably to blame for that. I think I've fixed it now, but I'd really appreciate a review of the changes I made. texcmp passes on r200 for me here now. Dave. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] radeon-rewrite branch merging.
Hi, So I have a goal to get a radeon driver that works on a bufmgr and that then can be used on non-mm/mm, and also where I can make DRI2 and FBOs work. So with that in mind and not wanting to write this 3 times, I've done a major refactoring of the radeon/r200/r300 drivers. I've refactored all the: buffer management, buffer swap + copy, texture and mipmap management, command submission handling, state + atom emission dma buffers, lock code, into common files for all 3 drivers, and re-used the same code in nearly the same ways across all 3. So far I've been working on getting the legacy buffer/command code into shape so I can merge this in place of the current drivers without suffering any major regressions. Then start adding the code necessary for DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to merge, I'd like people to bash on it, and report any major regressions above the current r100/r200/r300 codebases with these drivers. In order to get the mm/dri2 stuff working, I mainly need to 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon for this stuff at all I've made wrappers that I just need to use some magic to hook up. 2. add userspace clear paths for r100/r200. 3. fix lockups from DRI2 lockless :) 4. make it go fast. Most of the code was written by Nicolai and Jerome, I've just spent 2-3 weeks moving it around the place until it works!! I've done a series of piglit regressions and I have one or two to fix, but it seems to be only a couple left. Also any suggestions for things I should use to test this? I've mainly been doing piglit + gears + ipers + openarena when I can. Dave. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] radeon-rewrite branch merging.
Hi, So I have a goal to get a radeon driver that works on a bufmgr and that then can be used on non-mm/mm, and also where I can make DRI2 and FBOs work. r200 appears busted, but its wierd busted I'll blame the master merge and fix it tomorrow. Dave. So with that in mind and not wanting to write this 3 times, I've done a major refactoring of the radeon/r200/r300 drivers. I've refactored all the: buffer management, buffer swap + copy, texture and mipmap management, command submission handling, state + atom emission dma buffers, lock code, into common files for all 3 drivers, and re-used the same code in nearly the same ways across all 3. So far I've been working on getting the legacy buffer/command code into shape so I can merge this in place of the current drivers without suffering any major regressions. Then start adding the code necessary for DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to merge, I'd like people to bash on it, and report any major regressions above the current r100/r200/r300 codebases with these drivers. In order to get the mm/dri2 stuff working, I mainly need to 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon for this stuff at all I've made wrappers that I just need to use some magic to hook up. 2. add userspace clear paths for r100/r200. 3. fix lockups from DRI2 lockless :) 4. make it go fast. Most of the code was written by Nicolai and Jerome, I've just spent 2-3 weeks moving it around the place until it works!! I've done a series of piglit regressions and I have one or two to fix, but it seems to be only a couple left. Also any suggestions for things I should use to test this? I've mainly been doing piglit + gears + ipers + openarena when I can. Dave. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] radeon-rewrite branch merging.
r200 appears busted, but its wierd busted I'll blame the master merge and fix it tomorrow. Okay r200 gears is back, I think it was an artifact of not getting a clean build, along with fixing some warnings. Dave. Dave. So with that in mind and not wanting to write this 3 times, I've done a major refactoring of the radeon/r200/r300 drivers. I've refactored all the: buffer management, buffer swap + copy, texture and mipmap management, command submission handling, state + atom emission dma buffers, lock code, into common files for all 3 drivers, and re-used the same code in nearly the same ways across all 3. So far I've been working on getting the legacy buffer/command code into shape so I can merge this in place of the current drivers without suffering any major regressions. Then start adding the code necessary for DRI2/GEM/FBOs on top of it. I think this code is pretty close to read to merge, I'd like people to bash on it, and report any major regressions above the current r100/r200/r300 codebases with these drivers. In order to get the mm/dri2 stuff working, I mainly need to 1. get libdrm_radeon into a happy place. You don't require libdrm_radeon for this stuff at all I've made wrappers that I just need to use some magic to hook up. 2. add userspace clear paths for r100/r200. 3. fix lockups from DRI2 lockless :) 4. make it go fast. Most of the code was written by Nicolai and Jerome, I've just spent 2-3 weeks moving it around the place until it works!! I've done a series of piglit regressions and I have one or two to fix, but it seems to be only a couple left. Also any suggestions for things I should use to test this? I've mainly been doing piglit + gears + ipers + openarena when I can. Dave. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
On Mon, 9 Feb 2009, Kristian Høgsberg wrote: On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul bri...@vmware.com wrote: In terms of the build system, we'll initially default to the non-gallium build. To build with gallium I'll add some new configs like 'linux-gallium'. I haven't tried building gallium at all, but is there interest in adding support to the autoconf goo? I don't know how well it would fit in with the current semantics (--enable-driver=...), but I could take a look. I would definitely appreciate that. Maybe this is a dumb question, but is it possible to build both gallium drivers and classic drivers from the same tree at the same time? or is distro life going to be made shit yet again. Dave. thanks, Kristian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] merging gallium-0.2 branch to master
We can do either: - have some new build targets, like linux-gallium-dri etc, that build the drivers and put them in mesa/lib/xyz_dri.so No not the one we'd like. or - build both lots of drivers, and put the gallium ones in a new directory, like mesa/lib/gallium/xyz_dri.so I'd suspect we'd prefer this, then we can pick and choose at packaging time which drivers we want to ship in the OS. The 3rd option involves trying to define GALLIUM_DRIVERS/DRI_DRIVERS and making sure they don't intersect which just seems like a recipe for pain. Dave. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Problem with commit acae6f06 dri: fix crash in driGetConfigAttribIndex
the following commit 1724334d7c82abe55b6506dfe369df4facae6f06 dri: fix crash in driGetConfigAttribIndex Accessing a GLboolean via an int pointer on big-endian == bad. breaks 3D stuff on my radeon r5xx card: GLX no longer reports visuals with double buffering. I've attached the different outputs from glxinfo: I'm going to back this out, but it would be nice to fix properly, krh any ideas? Dave. --- mesa-broken-visual.log 2008-08-25 20:53:05.0 +0300 +++ mesa-OK-visual.log 2008-08-25 21:02:57.0 +0300 @@ -66,10 +66,12 @@ GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays -1 GLX Visuals +3 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- +0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None +0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x58 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 16 GLXFBConfigs: @@ -78,22 +80,19 @@ -- 0x59 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x5a 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow -0x5b 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None -0x5c 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow +0x5b 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None +0x5c 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x5d 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x5e 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow -0x5f 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None -0x60 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow +0x5f 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None +0x60 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x61 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x62 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow -0x63 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None -0x64 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow +0x63 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None +0x64 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x65 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x66 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow -0x67 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None -0x68 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow - +0x67 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None +0x68 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow If I revert that commit in either master branch or mesa_7_2_branch with the attached patch then 3D stuff works again. Any ideas what might be the problem? Regards, Stefan PS: I'm not subscribed to this list, so please CC: me. --- Stefan Becker E-Mail: [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Problem with commit acae6f06 dri: fix crash in driGetConfigAttribIndex
Having some incorrect visuals is better than a flat out unconditional server crash, isn't it? :-/ It's a major regression between an -rc3 and -rc4 of a Mesa release, that stops 3D working on a large number of x86 machinse vs a crash on some non-x86 machines. Ideally we find the real fix, !ideally we try and fix the unaligned problem without breaking things. Dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.1 rc 4
the GEM code. I have a feeling it might be easier for you to back-out the GEM code, make a branch, then re-add GEM on master. Besides, your git-fu is probably much better than mine. The branch should be called mesa_7_2_branch. I'll make a 7.1 release off that quickly, then designate it a bug-fix only branch, leading to the 7.2 release. OK, Eric? Okay I was bored on Sunday afternoon, so I did this stuff. I reverted the merge, created mesa_7_2_branch, reverted my revert, and shoved out master with that. So mesa_7_2_branch is where we expect 7.1 to be released from. Dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.1 rc 4
On Sun, Aug 17, 2008 at 12:23:06 +0200, Stefan Dirsch wrote: Looks like dri_bufmgr.h/intel_bufmgr.h are missing in the tarball. Could this be? See my other reply on mesa3d-dev, they're from libdrm git master. So I see a couple of ways to resolve this, 1) Back out GEM, release 7.1, put GEM back in - preferred by me. 2) release a libdrm/mesa which uses a kernel interface that hasn't made its way into a stable kernel tree. this ends up like TTM and we end up with pain. Dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.1 rc 4
It falls back gracefully though (I think TTM did as well, though this API is smaller in that it doesn't pass a huge gob of flags around), so if we think the libdrm bufmgr interface is stable there should be no problem. The problem is I am not that happy that the bufmgr interface is stable, its been changed quite a bit during GEM dev, and I forsee more changes to it to support other users... You missed the point it fails back gracefully at *runtime*, and if we do end up with a slight change to the interface in the kernel later we have code that could wait in hiding for the bits to be enabled in the kernel. Don't we keep saying libdrm is the interface these days anyway? So if that part is sane we should just release what's in libdrm master now or soon. But maybe I'm forgetting (ignorance is bliss) some aspect of the pain we had with TTM... for instance there are two direct GEM ioctls in the intel mesa code, libdrm currently publishes files it shouldn't, the plan is to build libdrm against kernel published files, however these files aren't in the kernel so I can release a libdrm against them. As I said on irc, you build a house (even a house of cards) from the bottom, doing it in reverse is not a good plan. There is no point having released userspace bits with no kernel to support them. So there will not be a libdrm release with any of this stuff in it before the upstream bits are in the kernel. We tried that with TTM, and we had lots of pain. Dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium (was Re: radeon r6xx DRM...)
Gallium might ultimately wind up in its own repository as a stand-alone project. Afterall, Gallium drivers could be used by APIs other than OpenGL. The question is mainly from a distro point of view what do we need to ship a gallium driver. The current method would mean we need a Mesa tree for normal DRI drivers and a gallium-mesa tree for gallium based drivers. This isn't brutal but I'd hate to spend a lot of time on the setup phase just to find the target moved. So if gallium is in a separate project will it need parts of Mesa to build. If it needs parts of mesa to build does it make sense in another project. Will the gallium/mesa interface move. so we end up having to provide synced version in any case, in which case why have different trees. Dave. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [ANNOUNCE] xorg-server 1.4.99.902
Okay here is a proposed patch against mesa which routes around TTM.
This leave me with the hope of creating a libdrm 2.3.1 which just
updates the APIs for all the other drivers, and still have mesa work.
This patch requires you to pass --enable-ttm-api to the mesa configure
if you need to use TTM APIs.
I think the X server might also need something similiar around dri2.
Dave.
From b85269252bb38769fcdd58dbcafb2c015f60f7d4 Mon Sep 17 00:00:00 2001
From: Dave Airlie [EMAIL PROTECTED]
Date: Wed, 28 May 2008 15:55:44 +1000
Subject: [PATCH] mesa/drm/ttm: allow build against non-TTM aware libdrm
I'll release a libdrm 2.3.1 without TTM apis included from a special
drm branch that should allow mesa 7.1 to build against it.
I've had to turn off DRI2 stuff.
---
configure.ac | 18
src/mesa/drivers/dri/common/dri_bufmgr.h | 38 +
src/mesa/drivers/dri/common/dri_util.c|6
src/mesa/drivers/dri/common/dri_util.h|3 +-
src/mesa/drivers/dri/intel/intel_bufmgr_ttm.c | 20 +
src/mesa/drivers/dri/intel/intel_bufmgr_ttm.h |8 +
src/mesa/drivers/dri/intel/intel_ioctl.c | 10 ++
7 files changed, 102 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index a250f75..a73c754 100644
--- a/configure.ac
+++ b/configure.ac
@@ -478,6 +478,19 @@ AC_ARG_ENABLE([driglx-direct],
[enable direct rendering in GLX for DRI @:@default=enabled@:@])],
[driglx_direct=$enableval],
[driglx_direct=yes])
+dnl ttm support
+AC_ARG_ENABLE([ttm-api],
+[AS_HELP_STRING([--enable-ttm-api],
+ [enable TTM API users])],
+[ttmapi=$enableval],
+[ttmapi=no])
+
+if test x$ttmapi = xyes; then
+save_CFLAGS=$CFLAGS
+CFLAGS=$LIBDRM_CFLAGS
+AC_CHECK_HEADERS([xf86mm.h],[],[AC_MSG_ERROR([xf86mm.h required for TTM.])],[#include stdint.h\n#include drm.h])
+CFLAGS=$save_CFLAGS
+fi
dnl Which drivers to build - default is chosen by platform
AC_ARG_WITH([dri-drivers],
@@ -516,6 +529,10 @@ if test $mesa_driver = dri; then
DEFINES=$DEFINES -DGLX_USE_TLS -DPTHREADS
fi
+if test x$ttmapi = xyes; then
+DEFINES=$DEFINES -DTTM_API
+fi
+
if test x$USING_EGL = x1; then
PROGRAM_DIRS=egl
fi
@@ -934,6 +951,7 @@ if test $mesa_driver = dri; then
dri_dirs=`echo $DRI_DIRS | $SED 's/^ *//;s/ */ /;s/ *$//'`
echo DRI drivers: $dri_dirs
echo DRI driver dir: $DRI_DRIVER_INSTALL_DIR
+echo TTM API support: $ttmapi
fi
dnl Libraries
diff --git a/src/mesa/drivers/dri/common/dri_bufmgr.h b/src/mesa/drivers/dri/common/dri_bufmgr.h
index 4593eaf..0a726dc 100644
--- a/src/mesa/drivers/dri/common/dri_bufmgr.h
+++ b/src/mesa/drivers/dri/common/dri_bufmgr.h
@@ -219,4 +219,42 @@ void dri_post_process_relocs(dri_bo *batch_buf);
void dri_post_submit(dri_bo *batch_buf, dri_fence **last_fence);
int dri_bufmgr_check_aperture_space(dri_bo *bo);
+#ifndef TTM_API
+/* reuse some TTM API */
+
+#define DRM_BO_MEM_LOCAL 0
+#define DRM_BO_MEM_TT 1
+#define DRM_BO_MEM_VRAM 2
+#define DRM_BO_MEM_PRIV0 3
+#define DRM_BO_MEM_PRIV1 4
+#define DRM_BO_MEM_PRIV2 5
+#define DRM_BO_MEM_PRIV3 6
+#define DRM_BO_MEM_PRIV4 7
+
+#define DRM_BO_FLAG_READ(1ULL 0)
+#define DRM_BO_FLAG_WRITE (1ULL 1)
+#define DRM_BO_FLAG_EXE (1ULL 2)
+#define DRM_BO_MASK_ACCESS (DRM_BO_FLAG_READ | DRM_BO_FLAG_WRITE | DRM_BO_FLAG_EXE)
+#define DRM_BO_FLAG_NO_EVICT(1ULL 4)
+
+#define DRM_BO_FLAG_MAPPABLE(1ULL 5)
+#define DRM_BO_FLAG_SHAREABLE (1ULL 6)
+
+#define DRM_BO_FLAG_CACHED (1ULL 7)
+
+#define DRM_BO_FLAG_NO_MOVE (1ULL 8)
+#define DRM_BO_FLAG_CACHED_MAPPED(1ULL 19)
+#define DRM_BO_FLAG_FORCE_CACHING (1ULL 13)
+#define DRM_BO_FLAG_FORCE_MAPPABLE (1ULL 14)
+#define DRM_BO_FLAG_TILE (1ULL 15)
+
+#define DRM_BO_FLAG_MEM_LOCAL (1ULL 24)
+#define DRM_BO_FLAG_MEM_TT (1ULL 25)
+#define DRM_BO_FLAG_MEM_VRAM (1ULL 26)
+
+#define DRM_BO_MASK_MEM 0xFF00ULL
+
+#define DRM_FENCE_TYPE_EXE 0x0001
+#endif
+
#endif
diff --git a/src/mesa/drivers/dri/common/dri_util.c b/src/mesa/drivers/dri/common/dri_util.c
index 5870208..6cae1eb 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -771,8 +771,10 @@ static void driDestroyScreen(__DRIscreen *psp)
(*psp-DriverAPI.DestroyScreen)(psp);
if (psp-dri2.enabled) {
+#ifdef TTM_API
drmBOUnmap(psp-fd, psp-dri2.sareaBO);
drmBOUnreference(psp-fd, psp-dri2.sareaBO);
+#endif
} else {
(void)drmUnmap((drmAddress)psp-pSAREA, SAREA_MAX);
(void)drmUnmap((drmAddress)psp-pFB, psp-fbSize);
@@ -904,6 +906,7 @@ dri2CreateNewScreen(int scrn, int fd, unsigned int sarea_handle,
const __DRIextension **extensions,
const __DRIconfig ***driver_configs, void *data)
{
+#ifdef TTM_API
static const __DRIextension
Re: [Mesa3d-dev] Mesa - Scitech? myOS - Miniature, Linux based OpenGL development system without X
1.) can you please tell me, since Scitech drivers are based on Mesa, why there is no mention of them on Mesa web site? Mesa is BSD licensed, anyone can and does take it and use it, the project may never find out or have any contact with the ppl using it... 2.) can you help me figure out, how come no one uses Scitech to do Linux without X even tho they are clean, working solution? and, i mean there is not a single Linux project using them, until now.. closed source? no idea what level the drivers are at.. i could not figure out 'Mesa minixgl', dont even know what exactly and where is the source code for it, i tried GGI, directFB and looked into other without X projects, but they so much trouble to compile, have dependencies that i want to get rid of, hard to isolate, clean or are simply too big. since all the 'Linux without X' drivers are based on Mesa anyway, i assume minixgl might be most simplistic and smallest, therefore best solution for me, so: is minixgl active? can someone point out if there is nice simple link that will download all necessary source of minixgl in ONE file? Miniglx isn't active in the sense of ppl do development on it to further it, I have deployed it in a number of OpenGL without X platforms, and I generally take the Mesa tree, make it work for what I want, and if the changes are applicable to upstream I push them back into the mesa tree, at this stage I'm probably the miniglx de-facto maintainer... miniglx ships as part of Mesa (but not in the tarballs..) you'll have to use git to grab the latest Mesa development tree then make linux-solo-x86 in theory should build a miniglx system, that along with a couple of hacks the drm to bypass the master authorisations should allow it to run on radeon or intel (granted I don't use radeon with it anymore so it may have bitrotted..) Miniglx currently in theory works hw-accelerated on radeon and intel i9xx hardware using the Linux kernel fb-drivers to do modesetting, and the drm to do the 3D acceleration, when the intel modesetting code is in the drm tree I'll make a miniglx to use that as opposed to fbdev just for a proof of concept and for perhaps an upcoming deployment into a production system.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] git merge tip to branch, cvs interactions
Oh yes, and there is some magic to create a branch on the remote, right? Am I able to do this myself or to I have to ask a grownup? Nope.. just push the branch, like git push origin my-new-branch:my-new-branch Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [ANNOUNCE] libdrm 2.2.0
Hi! In which kernel.org release will we find the updated kernel modules? Will it be necessary to run CVS modules? Depends on what you want, most features are in-kernel, newer things like TTM aren't in there yet... normally there is a 2 kernel delay, one cycle with features in -mm, then one cycle in Linus's rc cycle.. the kernel tree picks up changes from the DRM git tree as I see fit and as they become stable.. Dave. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Merged texmem branch
Sorry for the delay. I have to admit I find compressed textures really confusing for some reason, and basically do what I can to avoid them... Have you got an application or Mesa demo which you can point at doing the wrong thing? It'd be easier to work from something like that. Well I'm not sure if texcmp is broken, I can't test as I'm leaving the test running for a few days to see if anything falls out, but when it finishes I'll try and test it again.. I'll probably fix it myself but I doubt I'll get too much time before 6.5.2.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Merged texmem branch
Now that the merge is done I propose: 1. Finish up the glClear() parameter changes I started a week or two ago. 2. Get people to test the i915tex driver. I setup a machine at home running my gaming machine app which is a very heavy texture user, it uses compressed, rectangular and POT textures all over the place, Once I fixed the texture free functions, I had a problem where compressed textures appear busted at the moment with the driver, I had to add a hack in to stop it trying to copy more data than the buffer it was copying it into for a 1024x1024 compressed texture, but even with this the texture still displays wrong, I reported this to Keith by private e-mail, Apart from that though my app has been running for 1.5 days, I'll leave it going for as long as I can get away with it.. but it does look quite stable so I'd like to say thanks to the TG folks for this, I'll probably deploy 6.5.2 as my production driver, once I get compressed textures + miniglx fixed in it. Dave. 3. Try to stabilize the code, avoid checking in anything risky 4. Release Mesa 6.5.2 -- The TG group and I will mostly be off-line next week. So 6.5.2 is probably two weeks away, unless we want to make a big push for this weekend or something. -Brian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa-solo status?
I'm looking for an openGL setup without X11 for an embedded application. I tried to build mesa-solo (make linux-solo) but get problems with references to headers files like 'driver.h' and 'pciaccess.h' in file mesa/drivers/dri/i915/server/intel_dri.c. I guess other drivers will have similar problems. Can mesa-solo still be built? Or do I miss stuff, like the mini-GLX code? You need libdrm and libpciaccess installed before miniglx... you can just have libdrm if you don't want to run it on i915 hardware... just set DRI_DIRS to not include the i915... I'm running it here on 915 hardware the only thing is you must run intelfb accel=off for it to work.. Dave. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] moving drm CVS to git.
I'm in the process of moving DRM CVS to git, can people avoid using CVS from now on... When I get the last admin help the repo will be (in a few hours): git://anongit.freedesktop.org/git/mesa/drm I've decided to put the drm under the mesa project on fd.o as the dri project is pretty much retired with nearly all dev done in either mesa or x.org and I think there is more commonality with mesa in terms of developer lists. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GLX leakage
http://cvsweb.xfree86.org/cvsweb/xc/lib/GL/glx/glxext.c.diff?r1=1.2r2=1.3 The commit comment just says: 3377. DRI megapatch. This moves mesa to xc/extras, updates Mesa to version 3.2, adds full support and fifo code for 3dfx hardware, and updates the device driver to work with Linux 2.3 kernels (#3463, Daryll Strauss). What do we do now? :) Dig in the dri tree, http://webcvs.freedesktop.org/dri/xc/xc Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Unable to sync to [i915]
I want to sync glutSwapBuffers with vblank. I have developed an application with double buffering that uses glutSwapBuffer to refresh the screen. The application is getting 132 FPS and I notice some tearing on the screen. I want to sync swapBuffer with vblank in order to get 75 FPS and avoid tearing. What should I do? I'm using xorg 7.0 + mesa 6.5 + latest i915 driver from DRI. I'm not sure if vblank support is in Mesa 6.5.. it is in CVS alright.. you need to sest the env variable vblank_mode=3 to force vblank Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Moving to git ?
Just a quick question, i am wondering if anyone thought about moving mesa to git ? For the DRM I've contemplated it, I've just got a bit backed up with other things, but I'd like to move it in the next while at some point I'd personally like to see Mesa in git, I've locally got Mesa in git and try to do most of my work in it and stick the patches back in CVS, having Mesa in git saved me a lot of time tracking down those i915 regression recently using bisect.. Dave. Same question for DRM, i think this might help a lot the work of Dave for syncing with the linux kernel, and won't hurt much freebsd people. best, Jerome Glisse ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r300 max texture image units breaks swrast..
I'm guessing the corret answer if fix Mesa to use 16 instead of 8, but I'd like Brian or Keith to verify it, There's a bit of work to do to mesa before we double the number of texture units, particularly to swrast, but also tnl/ doesn't support this, afaik. For now, drivers are limited to 8 units, though this is a priority to fix. Okay I'll make the r300 driver default to 8 instead of 16 .. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] r300 max texture image units breaks swrast..
Okay I spent some time looking at the r300 span crap that no-one else was looking at and spending more time putting stupid hacks into the r300 driver... The problem is Mesa core defines MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and MAX_TEXTURE_IMAGE_UNITS to 8, this sizes a number of array including some in the SW rasterizer, The r300 defaults to setting MaxTextureImageUnits to 16 in its setup, however in _swrast_invalidate_state, this makes 490 for (i = 0 ; i ctx-Const.MaxTextureImageUnits ; i++) 491 swrast-TextureSample[i] = NULL; 492 } this fall off the end of the array and nuke the TexelBytes which segfaults the swrasteriser.. I'm guessing the corret answer if fix Mesa to use 16 instead of 8, but I'd like Brian or Keith to verify it, Thanks, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] 3D performance loss with i915 driver
Using CVS HEAD of xc (i.e. 6.9.0 Xorg) including bundled Mesa 6.4.1 I can reach 1110 FPS in glxgears and 27-30 FPS in ppracer (compared to 860 FPS glxgears and 11 FPS in ppracer using modular CVS HEAD of X.org and Mesa). I can confirm this one of the guys here was testing X.org 7.0 vs new i810/latest Mesa and hes seeing a big speed regression, I'll probably try and track this down next week unless someone here comes up with a reason first.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Compiling Mesa fbdev/DRI drivers without X installed
I recently tried to compile the Mesa fbdev/DRI drivers. Since I do not have X installed, this seemed to be exactly what I needed. Although the Mesa fbdev/DRI drivers do not require X, it seems that some X utilities and libs are at least required during the compilation process. I encountered a few problems which I managed to fix, and I thought I'd share them here for other people who may want to compile these drivers and have no X installed. I'm using a 3dfx Voodoo 3 card. Could it be that this one is not yet supported? That would explain why MINIGLX_SOURCES are commented out in src/mesa/drivers/dri/tdfx/Makefile, and that tdfxEngineRestore: not implemented message, wouldn't it? Am I better off using a Radeon card? Any ideas how to fix this? Well you figured it out.. it was commented out because no-one ever finished the code for it... radeon are the only miniglx card I know off that work .. and I don't test it that often, as the project I use them on as long ago picked a version of Mesa and stuck to it... but when I do fix things I fix them in Mesa src as well... I'm going to be porting miniglx to the i915 soon so if it is broken I'll get around to fixing it then.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Fast partial buffer swaps for GL compositing managers
efficiently done by using DrawBuffer (GL_FRONT) and CopyPixels. I've got a first attempt at accelerating copy pixels on r200 using bitblt, http://www.skynet.ie/~airlied/patches/dri/r200_copy_pixels_bitblt.diff Same code would be useful in radeon and r300 so I'd like to merge it .. However I was hitting a bad case with stencil or scissors enabled or something (memory is a abit hazy...) not allowing my fast path to be called.. it was probably simple to resolve, I had to drop it that point as I moved to working on 2D stuff on i915, and I've got all my radeons sitting in anti-static bags on my desk.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Re: x86-64 assembly dispatch stubs
That's odd. The dispatch routines are 16-byte aligned and the inlining doesn't grow the size of the routine above 16-bytes. Did actual .text size change, or just the library on-disk size? My impression is that as caching is all that matters, the overhead of branching to a cache hot function vs the overhead of inlining the work is probaly going to very very small.. this sort of discussion has been going on in kernel land for ages.. computers don't work like they did 10-15 years ago, inlining isn't the magic it once was.. smaller code size is much more important... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] I915_PARAM_LAST_DISPATCH missing
New libdrm needed.. Dave. On Thu, 9 Feb 2006, Johnson, Charles F wrote: I'm down to trying to build the i915_dri driver and am getting: gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../../drm/shared-core -I../../../../../include -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi -I../../../../../src/mesa/math -I../../../../../src/mesa/transform -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri `pkg-config --cflags libdrm` -Wall -Wmissing-prototypes -g -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS intel_ioctl.c -o intel_ioctl.o intel_ioctl.c: In function âintelGetLastFrameâ: intel_ioctl.c:49: error: âI915_PARAM_LAST_DISPATCHâ undeclared (first use in this function) intel_ioctl.c:49: error: (Each undeclared identifier is reported only once intel_ioctl.c:49: error: for each function it appears in.) intel_ioctl.c: In function âintelRefillBatchLockedâ: intel_ioctl.c:143: warning: pointer targets in assignment differ in signedness make: *** [intel_ioctl.o] Error 1 Anyone know about this one ?? Charles Johnson Channel Platform Solutions Group Intel Corporation [EMAIL PROTECTED] 503-712-5181 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GLX_EXT_texture_from_pixmap
I don't think I have CVS write access. It would be nice if you could fix that. You should have it now I think, ajax just added it .. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
