Re: [Mesa3d-dev] regression in r600g with a22aba4eae9b29db731487bce90e8292f7e82c72

2011-04-24 Thread Dave Airlie
On Sun, Apr 24, 2011 at 10:08 AM, Marek Olšák wrote: > > On Sun, Apr 24, 2011 at 1:15 AM, Dave Airlie wrote: >> >> Hi Brian, >> >> st/mesa: check image size before copy_image_data_to_texture() >> >> This causes a regression with NPOT textures in fbo-ge

[Mesa3d-dev] regression in r600g with a22aba4eae9b29db731487bce90e8292f7e82c72

2011-04-23 Thread Dave Airlie
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. -

Re: [Mesa3d-dev] ARB draw buffers + texenv program

2010-04-13 Thread Dave Airlie
On Wed, Apr 14, 2010 at 8:33 AM, Roland Scheidegger wrote: > On 13.04.2010 20:28, Alex Deucher wrote: >> On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson >> wrote: >>> On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger >>> wrote: >>>> On 13.04.2010

Re: [Mesa3d-dev] ARB draw buffers + texenv program

2010-04-13 Thread Dave Airlie
On Tue, Apr 13, 2010 at 11:42 PM, Roland Scheidegger wrote: > On 13.04.2010 02:52, Dave Airlie wrote: >> On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul wrote: >>> Dave Airlie wrote: >>>> Just going down the r300g piglit failures and noticed fbo-drawbuffers >>

Re: [Mesa3d-dev] ARB draw buffers + texenv program

2010-04-12 Thread Dave Airlie
> > (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 maski

Re: [Mesa3d-dev] ARB draw buffers + texenv program

2010-04-12 Thread Dave Airlie
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul 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

[Mesa3d-dev] piglit linking

2010-04-08 Thread Dave Airlie
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.

Re: [Mesa3d-dev] ARB draw buffers + texenv program

2010-04-07 Thread Dave Airlie
On Tue, Apr 6, 2010 at 10:47 PM, Keith Whitwell 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 texenv

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-05 Thread Dave Airlie
On Mon, Apr 5, 2010 at 6:06 PM, Chia-I Wu wrote: > On Mon, Apr 5, 2010 at 3:38 PM, Dave Airlie wrote: >> On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu wrote: >>> On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie wrote: >>>> On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu wrote

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-05 Thread Dave Airlie
On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu wrote: > On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie wrote: >> On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu wrote: >>> On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie wrote: >>>>> The attached patch fixes tfp test for m

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Dave Airlie
On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu wrote: > On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie wrote: >>> The attached patch fixes tfp test for me (with i915g).  Could you see if >>> r300g >>> passes the test with the patch? >>> The teximage callbac

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Dave Airlie
On Mon, Apr 5, 2010 at 12:49 PM, Chia-I Wu wrote: > On Sun, Apr 4, 2010 at 6:31 PM, Dave Airlie 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_s

[Mesa3d-dev] segfault in readpix demo with GL_OES_read_format on r300g

2010-04-04 Thread Dave Airlie
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/framebu

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Dave Airlie
> > 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: B

Re: [Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Dave Airlie
On Sun, Apr 4, 2010 at 8:31 PM, Dave Airlie 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.

[Mesa3d-dev] dri2 st + tfp set tex buffer2

2010-04-04 Thread Dave Airlie
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 s

[Mesa3d-dev] gallium + dri2 front buffer readback

2010-04-03 Thread Dave Airlie
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_co

[Mesa3d-dev] ARB draw buffers + texenv program

2010-04-02 Thread Dave Airlie
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 tes

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

2010-03-31 Thread Dave Airlie
On Tue, Mar 30, 2010 at 6:26 PM, Nicolai Haehnle wrote: > Reply to all this time... > > On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák wrote: >>> > 1) Branching and looping >>> > >>> > This is the most important one and there are 3 things which need to be >>> > done. >>> > * Unrolling loops and con

[Mesa3d-dev] llvmpipe autoconf attempt one

2010-03-28 Thread Dave Airlie
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 Descr

Re: [Mesa3d-dev] gallium cached bufmgr busy change

2010-03-23 Thread Dave Airlie
On Tue, Mar 23, 2010 at 11:41 PM, Luca Barbieri 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

Re: [Mesa3d-dev] gallium cached bufmgr busy change

2010-03-23 Thread Dave Airlie
On Mon, Mar 8, 2010 at 5:51 PM, Jose Fonseca 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

Re: [Mesa3d-dev] [mesa] r300g dri/st: OpenArena corruptions with mesa-7.8 and master GIT

2010-03-20 Thread Dave Airlie
On Sat, Mar 20, 2010 at 4:18 AM, Sedat Dilek 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

[Mesa3d-dev] r300g broken frontbuffer rendering.

2010-03-15 Thread Dave Airlie
Something in the recent statetracker and/or dri work Here is some gdb, I noticed this comment also: /* DRI co-state tracker currently overrides flush_frontbuffer. * When this is fixed, will need to pass the drawable in the * fourth parameter here so that when Mesa calls

Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!

2010-03-15 Thread Dave Airlie
On Wed, Mar 10, 2010 at 6:47 AM, Keith Whitwell wrote: > On Tue, 2010-03-09 at 12:43 -0800, Dave Airlie wrote: >> On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell wrote: >> > On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: >> >> On Tue, Mar 9, 2010 at

Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!

2010-03-09 Thread Dave Airlie
On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell wrote: > On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: >> On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell wrote: >> > This leaves r300g as the only remaining user of >> > pipe_winsys/u_simple_screen - which means we can rename that code >>

Re: [Mesa3d-dev] gallium cached bufmgr busy change

2010-03-08 Thread Dave Airlie
On Tue, Mar 9, 2010 at 11:30 AM, Luca Barbieri 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

Re: [Mesa3d-dev] gallium cached bufmgr busy change

2010-03-07 Thread Dave Airlie
On Sun, Mar 7, 2010 at 9:44 PM, Luca Barbieri 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

[Mesa3d-dev] gallium cached bufmgr busy change

2010-03-06 Thread Dave Airlie
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

[Mesa3d-dev] [rfc] to SpanRenderStart to avoid texture mapping overheads

2010-03-06 Thread Dave Airlie
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

Re: [Mesa3d-dev] Gallium software fallback/draw command failure

2010-02-28 Thread Dave Airlie
On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt 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 >>

Re: [Mesa3d-dev] Mesa removals

2010-02-22 Thread Dave Airlie
> > 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 revivi

Re: [Mesa3d-dev] Mesa (master): gallium: fix more missing includes from various places

2010-02-04 Thread Dave Airlie
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=3584a44270a7f3a04e187bd79b5373314514

[Mesa3d-dev] gallium: ARB_half_float_vertex

2010-01-26 Thread Dave Airlie
e 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 Date: Tue, 26 Jan 20

Re: [Mesa3d-dev] gallium docs

2010-01-25 Thread Dave Airlie
> > 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 > thems

Re: [Mesa3d-dev] ARB_half_float_vertex support branch

2010-01-17 Thread Dave Airlie
> > 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. > >

[Mesa3d-dev] ARB_half_float_vertex support branch

2010-01-17 Thread Dave Airlie
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

[Mesa3d-dev] gallium: add overlapping blit support to u_blitter

2010-01-06 Thread Dave Airlie
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 Date: Thu, 7

[Mesa3d-dev] libdrm_radeon API change

2009-12-21 Thread Dave Airlie
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

Re: [Mesa3d-dev] flushing vertices in radeon swtcl

2009-09-23 Thread Dave Airlie
> > > 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

Re: [Mesa3d-dev] flushing vertices in radeon swtcl

2009-09-23 Thread Dave Airlie
> > 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 worke

Re: [Mesa3d-dev] [PATCH 0/20] Establish feature convensions

2009-09-21 Thread Dave Airlie
> > > > This patch series focuses on core mesa. The biggest thing missing is a > > convension for drivers to enable extensions. I think some refactorings > > are needed before a convension can be established. > > I'm actually not too enthusiastic about these patches. > > When we omit a feature

Re: [Mesa3d-dev] r300: piglit test results on Mesa 7.6 branch

2009-09-21 Thread Dave Airlie
> 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

Re: [Mesa3d-dev] [PATCH] fix compilation errors due to meta function renames

2009-09-20 Thread Dave Airlie
> On Sun, Sep 20, 2009 at 9:00 PM, Chia-I Wu wrote: > > The attached patches fix missing symbols in meta/st and a compilation > > error in intel dri driver. > > Committed. Thanks. Sorry for the screw-ups. > I think gallium is still broken, just doing a rebuild now, undefined symbol: _swrast_

Re: [Mesa3d-dev] Mesa (mesa_7_6_branch): i965: do a flush in clear, fix openarena render issue,

2009-09-18 Thread Dave Airlie
> >> > >>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 regr

Re: [Mesa3d-dev] Mesa (mesa_7_6_branch): i965: do a flush in clear, fix openarena render issue,

2009-09-17 Thread Dave Airlie
> >>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 delay

[Mesa3d-dev] flushing vertices in radeon swtcl

2009-09-16 Thread Dave Airlie
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

Re: [Mesa3d-dev] Mesa 7.6 branch coming

2009-09-03 Thread Dave Airlie
> > 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 *a

Re: [Mesa3d-dev] Mesa 7.6 branch coming

2009-09-03 Thread Dave Airlie
> > 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 of

[Mesa3d-dev] Loader ABI break Re: [PATCH 0/4] RESEND: Fix races in glapi

2009-08-25 Thread Dave Airlie
> > 3d drivers without rebuilding the xserver. > Old libGL.so won't load the DRI drivers compiled with this commit. This > is known, but I must admit that I forgot xserver counts as an old > libGL.so... > > I just had a quick look at it, and I think this can be fixed by defining > _glapi_SingleT

Re: [Mesa3d-dev] cairo-dock insanity what to do?

2009-08-04 Thread Dave Airlie
> > > > 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

[Mesa3d-dev] cairo-dock insanity what to do?

2009-07-22 Thread Dave Airlie
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

[Mesa3d-dev] enums.c debug broken

2009-07-14 Thread Dave Airlie
54f425b5cefd1e40f315a4f8747b9a3db29ab9d4 or something around then broke the enums.c it looks like someone hand edited the file with the don't hand edit this file on top :-) Brian? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI

[Mesa3d-dev] radeon-rewrite merged to master

2009-06-11 Thread Dave Airlie
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 :) Ho

Re: [Mesa3d-dev] More radeon-rewrite patches

2009-06-07 Thread Dave Airlie
> > > > 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 increa

Re: [Mesa3d-dev] More radeon-rewrite patches

2009-06-06 Thread Dave Airlie
gned-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 lo

Re: [Mesa3d-dev] DMA buffer management + KMS

2009-05-25 Thread Dave Airlie
> > > > 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 str

Re: [Mesa3d-dev] DMA buffer management + KMS

2009-05-25 Thread Dave Airlie
> > 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.

[Mesa3d-dev] [rfc patch] dri drawable ref counting

2009-04-15 Thread Dave Airlie
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/

Re: [Mesa3d-dev] Mesa 7.5 plans

2009-04-07 Thread Dave Airlie
> > 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 develo

[Mesa3d-dev] piglit texture test issue

2009-03-29 Thread Dave Airlie
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

[Mesa3d-dev] FBOs and texture formats

2009-03-23 Thread Dave Airlie
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,

Re: [Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.

2009-03-22 Thread Dave Airlie
> > 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 t

[Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.

2009-03-21 Thread Dave Airlie
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

Re: [Mesa3d-dev] Mesa regression

2009-03-08 Thread Dave Airlie
> 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: As

Re: [Mesa3d-dev] merging gallium-0.2 branch to master

2009-02-13 Thread Dave Airlie
> > 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 p

Re: [Mesa3d-dev] radeon-rewrite branch merging.

2009-02-12 Thread Dave Airlie
> > 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, > > lastL

Re: [Mesa3d-dev] radeon-rewrite branch merging.

2009-02-11 Thread Dave Airlie
> > 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

Re: [Mesa3d-dev] radeon-rewrite branch merging.

2009-02-11 Thread Dave Airlie
> 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 n

[Mesa3d-dev] radeon-rewrite branch merging.

2009-02-11 Thread Dave Airlie
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

Re: [Mesa3d-dev] merging gallium-0.2 branch to master

2009-02-09 Thread Dave Airlie
> 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

Re: [Mesa3d-dev] merging gallium-0.2 branch to master

2009-02-09 Thread Dave Airlie
On Mon, 9 Feb 2009, Kristian Høgsberg wrote: > On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson wrote: > > On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul 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 config

Re: [Mesa3d-dev] Problem with commit acae6f06 "dri: fix crash in driGetConfigAttribIndex"

2008-08-26 Thread Dave Airlie
> > 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

Re: [Mesa3d-dev] Problem with commit acae6f06 "dri: fix crash in driGetConfigAttribIndex"

2008-08-26 Thread Dave Airlie
> 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'v

Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.1 rc 4

2008-08-24 Thread Dave Airlie
> 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 des

Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.1 rc 4

2008-08-19 Thread Dave Airlie
> 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

Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.1 rc 4

2008-08-19 Thread Dave Airlie
> 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

Re: [Mesa3d-dev] gallium (was Re: radeon r6xx DRM...)

2008-06-04 Thread Dave Airlie
> > 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 t

Re: [Mesa3d-dev] [ANNOUNCE] xorg-server 1.4.99.902

2008-05-27 Thread Dave Airlie
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

Re: [Mesa3d-dev] 3D support for > 2048x2048 on intel drivers

2007-07-26 Thread Dave Airlie
On Thu, 26 Jul 2007, Chase Douglas wrote: > I see that I need libdrm 2.3.1 for i915tex, but I can't find any way to > get libdrm 2.3.0. The latest in git is 2.3.0, and though I can find > RPMS, I have no clue how to get it. Does anyone know where I can get it? Git should be sufficent and I thoug

Re: [Mesa3d-dev] Mesa - Scitech? myOS - Miniature, Linux based OpenGL development system without X

2007-03-31 Thread Dave Airlie
> 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 ou

Re: [Mesa3d-dev] git merge tip to branch, cvs interactions

2007-01-15 Thread Dave Airlie
> 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 / airli

Re: [Mesa3d-dev] [ANNOUNCE] libdrm 2.2.0

2006-11-21 Thread Dave Airlie
> 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 cyc

Re: [Mesa3d-dev] Merged texmem branch

2006-11-02 Thread Dave Airlie
> > 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

Re: [Mesa3d-dev] Merged texmem branch

2006-11-01 Thread Dave Airlie
> > 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

Re: [Mesa3d-dev] Moving Mesa to GIT?

2006-10-10 Thread Dave Airlie
> just move that to > > git://git.freedesktop.org/git/mesa.git You need to move it to mesa/mesa.git as we have a meas dir already.. You probably need to regenerate the tree from scratch or have you got a fully up-to-date authors list? Dave. -- David Airlie, Software Engineer http://www.skyn

Re: [Mesa3d-dev] Mesa-solo status?

2006-10-05 Thread Dave Airlie
> > 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 sim

Re: [Mesa3d-dev] GLX leakage

2006-07-13 Thread Dave Airlie
> > http://cvsweb.xfree86.org/cvsweb/xc/lib/GL/glx/glxext.c.diff?r1=1.2&r2=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

[Mesa3d-dev] moving drm CVS to git.

2006-07-13 Thread Dave Airlie
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 reti

Re: [Mesa3d-dev] Unable to sync to [i915]

2006-07-04 Thread Dave Airlie
> > 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

Re: [Mesa3d-dev] Moving to git ?

2006-06-13 Thread Dave Airlie
> I still haven't used git yet myself, but it sounds pretty good. > > I'd be willing to look into it, perhaps after the next Mesa release. OK? Fine by me, If you wand the virtues of git extoled, talk to keithp :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlie

Re: [Mesa3d-dev] Moving to git ?

2006-06-13 Thread Dave Airlie
> 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

Re: [Mesa3d-dev] Re: state of r200-copy-pixels patch for mesa ?

2006-05-24 Thread Dave Airlie
I think Dave Airlie created a more appropriate patch for accelerating CopyPixels. My patch is at http://www.skynet.ie/~airlied/patches/dri/r200_copy_pixels_bitblt.diff However it was falling back too often for my liking so I think it is correct, just a bit too cautious... I haven't

Re: [Mesa3d-dev] r300 max texture image units breaks swrast..

2006-05-11 Thread Dave Airlie
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

[Mesa3d-dev] r300 max texture image units breaks swrast..

2006-05-11 Thread Dave Airlie
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 arra

Re: [Mesa3d-dev] 3D performance loss with i915 driver

2006-05-02 Thread Dave Airlie
On Tue, 2006-05-02 at 14:23 +0200, Lukas Hejtmanek wrote: On Tue, May 02, 2006 at 11:51:05AM +0100, Alan Hourihane wrote: The problem here is batchbuffers. Due to rotation being able to shuffle memory around it wasn't possible to support batchbuffers in agp space as the 2D driver could rip up

Re: [Mesa3d-dev] 3D performance loss with i915 driver

2006-04-27 Thread Dave Airlie
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

Re: [Mesa3d-dev] Missing X_GLXvop_BindTexImageEXT

2006-03-16 Thread Dave Airlie
In the case of X.org, OTOH, you are *only* talking about the software rasterizer for Indirect GLX. I don't think it's unreasonable to say that the policy could change to make that track the Mesa stable branch or even just to track Mesa releases. Actually with all this talk of new extensions

Re: [Mesa3d-dev] Missing X_GLXvop_BindTexImageEXT

2006-03-16 Thread Dave Airlie
The GLX proto headers are all that is required from Xorg, otherwise we end up with two copies that can get out of sync with each other.. the GL proto module is very small I'm no expert on these things, but doesn't one of the header locations define the library capabilities and the oth

Re: [Mesa3d-dev] Missing X_GLXvop_BindTexImageEXT

2006-03-16 Thread Dave Airlie
It seems to me that whatever reason Xorg needs to build mesa for (I'm guessing the indirect GLX software rasterizer) is a mistake. If mesa is to be built, it should be built within the tree it is developed. That might mean that Mesa should learn how to build itself in a form suitable for use

  1   2   >