Ian Romanick wrote:
Keith Whitwell wrote:
Here's a patch that mainly works. I've still seen the odd case of the
texture apparently getting uploaded to the backbuffer.
...but *only* if you have a kernel module installed that understands
rectangle state. As it is, the code in
Ian Romanick wrote:
I only noticed this because when I try to insmod the new radeon.o, it
fails on an undefined symbol mmu_cr4_features. The wierd part is that
/boot/System.map-2.4.21-rc2-ac2 shows it as being in global BSS
(c02ccd0c B mmu_cr4_features), *but* /proc/ksyms doesn't show it. I
Keith Whitwell wrote:
Here's a patch that mainly works. I've still seen the odd case of the
texture apparently getting uploaded to the backbuffer.
...but *only* if you have a kernel module installed that understands
rectangle state. As it is, the code in radeon_state_init.c allows
texture
while trying to activate the 3rd TMU on radeon
I discovered that txr states get emitted even
in the yuvsqare (and multiarb) demo
(which use only standard textures):
(RADEON_DEBUG=state and yuvsqare demo:)
radeonBindTexture( 0x8132dc8 ) unit=0
radeonEmitState
radeonEmitState - lost context
Andreas Stenglein wrote:
while trying to activate the 3rd TMU on radeon
I discovered that txr states get emitted even
in the yuvsqare (and multiarb) demo
(which use only standard textures):
(RADEON_DEBUG=state and yuvsqare demo:)
radeonBindTexture( 0x8132dc8 ) unit=0
radeonEmitState
Am 2003.06.13 17:00:20 +0200 schrieb(en) Keith Whitwell:
Andreas Stenglein wrote:
[...]
btw. heres also a patch for mplayer vo_gl.c which uses
GL_NV_texture_rectangle.
I sent a (sligtly) older version to mplayer-dev-eng, but
unfortunately it
got caught by some filter/ wasnt released by the
On Thu, Jun 12, 2003 at 04:54:47PM -0600, Brian Paul wrote:
|
| An ARB extension for NPOT 1D, 2D, 3D and cube textures is coming.
| Parameterized texture coordinates (i.e. [0,1] range) will be used,
| rather than [0,w]x[0,h] like GL_NV_texture_rectangle.
There's interest in supporting
On Tue, 2003-06-10 at 13:14, Keith Whitwell wrote:
Andreas Stenglein wrote:
3) in radeon_ioctl.c, function radeonEmitVbufPrim()
the first cmd is cleared before filled with the cmd_type:
cmd[0].i = 0;
cmd[0].header.cmd_type = RADEON_CMD_PACKET3_CLIP;
should this be
On Thu, Jun 12, 2003 at 11:00:18PM +0200, Michel D?nzer wrote:
On Tue, 2003-06-10 at 13:14, Keith Whitwell wrote:
Andreas Stenglein wrote:
3) in radeon_ioctl.c, function radeonEmitVbufPrim()
the first cmd is cleared before filled with the cmd_type:
cmd[0].i = 0;
On Thu, 2003-06-12 at 23:26, [EMAIL PROTECTED] wrote:
On Thu, Jun 12, 2003 at 11:00:18PM +0200, Michel D?nzer wrote:
On Tue, 2003-06-10 at 13:14, Keith Whitwell wrote:
Andreas Stenglein wrote:
3) in radeon_ioctl.c, function radeonEmitVbufPrim()
the first cmd is cleared before
On Fri, Jun 13, 2003 at 12:00:12AM +0200, Michel D?nzer wrote:
It has no choice
but to take the data as it gets it from the client?
Yes, but initially, the interesting piece of a header is the first char, and
the kernel checks the first char (and then correctly skips the length of the
union
Just a heads-up regarding non-power of two (NPOT) textures.
An ARB extension for NPOT 1D, 2D, 3D and cube textures is coming.
Parameterized texture coordinates (i.e. [0,1] range) will be used,
rather than [0,w]x[0,h] like GL_NV_texture_rectangle.
I'll probably implement this feature in core
Michel Dänzer wrote:
On Tue, 2003-06-10 at 13:14, Keith Whitwell wrote:
Andreas Stenglein wrote:
3) in radeon_ioctl.c, function radeonEmitVbufPrim()
the first cmd is cleared before filled with the cmd_type:
cmd[0].i = 0;
cmd[0].header.cmd_type = RADEON_CMD_PACKET3_CLIP;
should this be
On Fri, 2003-06-13 at 00:31, [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2003 at 12:00:12AM +0200, Michel D?nzer wrote:
It has no choice
but to take the data as it gets it from the client?
Yes, but initially, the interesting piece of a header is the first char, and
the kernel checks the
Keith Whitwell wrote:
Andreas Stenglein wrote:
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
OK, the final piece of the puzzle fell into place. Without the radeon docs
you might hav had trouble find this -- basically, the radeon still expects
Andreas Stenglein wrote:
Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell:
Keith Whitwell wrote:
Andreas Stenglein wrote:
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
OK, the final piece of the puzzle fell into place. Without the
Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell:
Keith Whitwell wrote:
Andreas Stenglein wrote:
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
OK, the final piece of the puzzle fell into place. Without the
radeon docs you might hav had
Keith Whitwell wrote:
Andreas Stenglein wrote:
Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell:
Keith Whitwell wrote:
Andreas Stenglein wrote:
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
OK, the final piece of the puzzle fell
Am 2003.06.10 13:14:28 +0200 schrieb(en) Keith Whitwell:
[...]
I was thinking that this would be a fairly easy option:
a) Disable TCL for all rectangular texture operations
b) Insert a new stage to the swtcl pipeline, based on
Mesa/src/tnl/t_vb_texmat.c, to perform a 1/w, 1/h scale to all
Keith Whitwell wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Andreas Stenglein wrote:
Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell:
Keith Whitwell wrote:
Andreas Stenglein wrote:
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
Andreas Stenglein wrote:
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
Andreas,
Applied this today had a brief look.
I needed to bump the version number in shared/drm/radeon.h to 1.9.0 before the
extensions were enabled. Maybe this got missed from
Andreas Stenglein wrote:
hello,
Am 2003.06.09 18:05:35 +0200 schrieb(en) Keith Whitwell:
Andreas,
Applied this today had a brief look.
I needed to bump the version number in shared/drm/radeon.h to 1.9.0
before the extensions were enabled. Maybe this got missed from the diff?
I didn't want
Am 2003.06.09 23:19:16 +0200 schrieb(en) Keith Whitwell:
[...]
I've been playing a bit more -- it's kind of odd what works
doesn't... I haven't really got a handle on it yet...
Keith
I modified yuvrect so that it uploads an rgb-image, (rgbrect)
result (as expected): doesnt work.
btw: its
Keith Whitwell wrote:
Andreas Stenglein wrote:
hello,
Am 2003.06.09 18:05:35 +0200 schrieb(en) Keith Whitwell:
Andreas,
Applied this today had a brief look.
I needed to bump the version number in shared/drm/radeon.h to 1.9.0
before the extensions were enabled. Maybe this got missed from
Andreas Stenglein wrote:
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
I find the radeon_sanity.c output very helpful when things just arent working.
Here's a patch to bring it uptodate with your changes. If you run it,
you'll see that the
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
greetings,
Andreas
Only in mod_trunk: build
Only in trunk_orig: cvs-logdatei
Only in trunk_orig: update_cvs
diff -ru trunk_orig/xc/xc/extras/Mesa/src/enums.c mod_trunk/xc/xc/extras/Mesa/src/enums.c
I think I missed some lines in
file radeon_texstate.c function
import_tex_obj_state()
...
cmd[TEX_PP_TXSIZE] = texobj-pp_txsize; /* NPOT only! */
cmd[TEX_PP_TXPITCH] = texobj-pp_txpitch; /* NPOT only! */
...
unfortunately it isnt possible to just copy from r200 ;)
since the registers are on
I copied together (from r200 driver)
a patch which enables GL_NV_texture_rectangle
on radeon.
The yuvrect.c test from mesa seems to work,
but texrect.c doesnt. strange.
Other issues:
1) radeonEmitBlit uses an already shifted
color_fmt, which is defined in radeon_reg.h,
r200EmitBlit uses an
28 matches
Mail list logo
