Hi all,
On Thu, Mar 18, 2010 at 10:11:12AM +0800, Chia-I Wu wrote:
> I've created a new branch, gallium-st-api-dri, that switches st/dri from
> st_public.h to st_api.h. The branch starts with four commits that move DRI1
> support to a new file, followed by 2 commits to switch st/dri to st_api.h.
Hi Chia-I (hope this is the first name),
>I've merged the branch. All Gallium DRI drivers now use st_api.h
>instead of st_public.h. If you notice any regression due the merge,
>please let me know so that I can work on it.
The last days I have tested your gallium-st-api-dri GIT branch by
merging
On Sun, Mar 21, 2010 at 5:19 PM, Sedat Dilek wrote:
> Hi Chia-I (hope this is the first name),
It is :)
>>I've merged the branch. All Gallium DRI drivers now use st_api.h
>>instead of st_public.h. If you notice any regression due the merge,
>>please let me know so that I can work on it.
> The la
On Sun, Mar 21, 2010 at 10:33 AM, Chia-I Wu wrote:
> On Sun, Mar 21, 2010 at 5:19 PM, Sedat Dilek
> wrote:
[...]
>> Even I see OpenArena got a boost from ~25fps (7.8 GIT) to ~32fps
>> (master GIT incl. gallium-st-api-dri merge)
>> $ cat oa_benchmark.txt
>> s...@seduxbox:~/src/anholt_oa-benchmark
Hi Chia-I Wu,
I've just updated my copy of Mesa master today after your
merge and the latest commits(from about 11:30 am GMT).I build Mesa with
these configure options:
./configure --prefix=/usr --enable-32-bit --enable-xcb
--enable-gallium-nouveau --with-state-trackers=dri,egl,
Maybe you try a git-hard-reset to the commit-no of the merge and then
compile again.
(To see if it is related to gallium-st-api-dri merge)
$ git reset --hard 12deb9e6ca76d222badf71c8643e84640673e86d
--
Sedat
--
Download
That was commit 9ec29e31919e85f9230867f43841c0e74be930d3 when doing a
pristine build. I reverted it for now.
On Sun, Mar 21, 2010 at 2:31 PM, STEVE555 wrote:
>
> Hi Chia-I Wu,
> I've just updated my copy of Mesa master today after your
> merge and the latest commits(from about 1
On Sun, Mar 21, 2010 at 8:31 PM, STEVE555 wrote:
> I've just updated my copy of Mesa master today after your
> merge and the latest commits(from about 11:30 am GMT).I build Mesa with
> these configure options:
> ./configure --prefix=/usr --enable-32-bit --enable-xcb
> --enable-ga
Please do "git pull --rebase origin" instead of "git pull origin" to avoid
"Merge branch 'master' of ..." commits.
-Marek
On Sun, Mar 21, 2010 at 2:40 PM, George Sapountzis wrote:
> That was commit 9ec29e31919e85f9230867f43841c0e74be930d3 when doing a
> pristine build. I reverted it for now.
>
>
On Sun, Mar 21, 2010 at 4:31 PM, Marek Olšák wrote:
> Please do "git pull --rebase origin" instead of "git pull origin" to avoid
> "Merge branch 'master' of ..." commits.
>
yes, i left them because the intervening commits happened between a
local 'git clean -fdx' and a 'git push' ... to denote th
Hi George,
Your revert commit fixed the probelm,thank you very much
indeed.
Regards,
STEVE555
George Sapountzis wrote:
>
> On Sun, Mar 21, 2010 at 4:31 PM, Marek Olšák wrote:
>> Please do "git pull --rebase origin" instead of "git pull origin" to
>> avoid
>> "Merge br
http://bugs.freedesktop.org/show_bug.cgi?id=25994
--- Comment #13 from Loose Vladimir 2010-03-21 08:51:23
PST ---
Happy to say, someone with nickname pino had looked at this bug report and
tested shader.c and Mortal fragment shader on his hardware:
Chipset: GM45
System architecture: x86
xs
On Sun, Mar 21, 2010 at 4:46 AM, Chia-I Wu wrote:
> On Fri, Mar 19, 2010 at 09:57:41PM +0200, George Sapountzis wrote:
>> The timing of the first attempt was unfortunate because it was in the
>> middle of a re-factoring I had not realized it was happening. The good
>> thing is that after the chang
scons dri=no drivers=softpipe or llvmpipe
glxgears: symbol lookup error:
/home/xavier/app/mesa/build/linux-x86_64/lib/libGL.so.1: undefined
symbol: gallium_soft_create_screen
Works after these two reverts :
Revert "gallium: add soft screen helper"
This reverts commit f87a5f6499f51f651c2a9
Can you please try a clean build ?
softpipe_create_screen is defined in the newly added file
soft_screen.c and maybe you did not rebuild drm/sw
If I actually broke this as well, admittedly I should have stayed away
from the computer today
On Sun, Mar 21, 2010 at 6:42 PM, Xavier Chantry
wrote:
On Sun, Mar 21, 2010 at 6:50 PM, George Sapountzis
wrote:
> Can you please try a clean build ?
>
> softpipe_create_screen is defined in the newly added file
> soft_screen.c and maybe you did not rebuild drm/sw
>
s/softpipe_create_screen/gallium_soft_create_screen/ in the above
sentence, only to c
On Sun, Mar 21, 2010 at 6:50 PM, George Sapountzis
wrote:
> Can you please try a clean build ?
>
> softpipe_create_screen is defined in the newly added file
> soft_screen.c and maybe you did not rebuild drm/sw
>
> If I actually broke this as well, admittedly I should have stayed away
> from the co
George,
This is basically a reproduction of a facility I had in target-helpers
previously (swrast_screen.c or similar), which I removed after
feedback from Jose that supporting it with scons created more ugliness
than we saved in the C code.
This change breaks layering in the build system by maki
On Sun, Mar 21, 2010 at 6:23 PM, George Sapountzis
wrote:
> On Sun, Mar 21, 2010 at 6:50 PM, George Sapountzis
> wrote:
>> Can you please try a clean build ?
>>
>> softpipe_create_screen is defined in the newly added file
>> soft_screen.c and maybe you did not rebuild drm/sw
>>
>> If I actually b
On Sun, Mar 21, 2010 at 7:22 PM, Keith Whitwell
wrote:
> George,
>
> This is basically a reproduction of a facility I had in target-helpers
> previously (swrast_screen.c or similar), which I removed after
> feedback from Jose that supporting it with scons created more ugliness
> than we saved in t
On Sun, Mar 21, 2010 at 7:43 PM, George Sapountzis
wrote:
> On Sun, Mar 21, 2010 at 7:22 PM, Keith Whitwell
> wrote:
>> George,
>>
>> This is basically a reproduction of a facility I had in target-helpers
>> previously (swrast_screen.c or similar), which I removed after
>> feedback from Jose that
There is bug in r200 swtnl fallback that hwtnl state is emited in swtnl flush.
Bug causes emit size to be larger that excepted which might cause crash in some
corner cases.
Signed-off-by: Pauli Nieminen
---
tests/all.tests |1 +
tests/bugs/CMakeLists.txt
On Sun, Mar 21, 2010 at 5:57 PM, George Sapountzis
wrote:
> On Sun, Mar 21, 2010 at 7:43 PM, George Sapountzis
> wrote:
>> On Sun, Mar 21, 2010 at 7:22 PM, Keith Whitwell
>> wrote:
>>> George,
>>>
>>> This is basically a reproduction of a facility I had in target-helpers
>>> previously (swrast_s
On Fri, Mar 19, 2010 at 06:26:03PM +0100, Nicolai Haehnle wrote:
> On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen wrote:
> > So, identify the volatile interfaces, and the more stable interfaces,
> > and then isolate the volatile ones, and then you come to only one
> > conclusion.
>
> Except that
On Fri, Mar 19, 2010 at 12:44:39PM -0500, Bridgman, John wrote:
> Pulling drm back out of the kernel tree seems like a hard sell, but the
> ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for
> grouping.
>
> I guess the core question is whether we expect the X-to-ddx and
On Fri, Mar 19, 2010 at 11:33:02AM -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I've been busy trying to get a release out the door, so I haven't looked
> at these patches yet. I won't have a chance to look at the patches
> until at least late next week. I als
http://bugs.freedesktop.org/show_bug.cgi?id=27150
--- Comment #6 from Alan 2010-03-21 18:58:07 PST ---
I also noticed that glBlitFramebufferEXT is defined on the header file but the
symbol is not exported into libGL.so for both 32bit and 64bit.
--
Configure bugmail: http://bugs.freedeskto
http://bugs.freedesktop.org/show_bug.cgi?id=27150
--- Comment #7 from Chia-I Wu 2010-03-21 20:10:05 PST ---
The gl* functions are generated from glAPI XMLs and scripts. The original bug
was a bug in the scripts, and is fixed. On the other hand, the XMLs do say
that glBlitFramebuffer should
http://bugs.freedesktop.org/show_bug.cgi?id=27216
Vinson Lee changed:
What|Removed |Added
AssignedTo|mesa3d- |bri...@vmware.com
|d...@l
29 matches
Mail list logo