Currently, the performance when streaming video through glTexSubImage2D is
very low. In my test program and with mplayer, I get approximately 8 fps in
720x576 on my Radeon 7500 with texmem-branch from a couple of weeks ago.
glDrawPixels is equally slow. I assume glTexSubImage2D is supposed
Morten Hustveit wrote:
Currently, the performance when streaming video through glTexSubImage2D is
very low. In my test program and with mplayer, I get approximately 8 fps in
720x576 on my Radeon 7500 with texmem-branch from a couple of weeks ago.
glDrawPixels is equally slow. I assume
Morten Hustveit wrote:
Currently, the performance when streaming video through glTexSubImage2D is
very low. In my test program and with mplayer, I get approximately 8 fps in
720x576 on my Radeon 7500 with texmem-branch from a couple of weeks ago.
glDrawPixels is equally slow. I assume
Check out marriedbutyetalone!]
Married But Lonely
Married But Lonely is an exclusive
site of lonely women
looking for sex dates with you! We have
thousands of married
women listed nationwide and in over 10
countries! Plus, you
get an adult cyberpass which automatically
and
I've been looking at the texmem branch and have found a few problems. I
wanted to explain the problems I found and get some feedback before
commiting any changes or putting a patch together.
The first item is the cause of the texture corruption with multiple
contexts that I have seen with both
On Fri, 31 Jan 2003, Arkadi Shishlov wrote:
On Fri, Jan 31, 2003 at 10:26:13AM -0800, Ian Romanick wrote:
There are two typical ways to go about imporving texture upload
performance in OpenGL applications. One is through the use of OpenGL
extensions. There are several extensions
On Fri, Jan 31, 2003 at 04:33:36PM -0500, Leif Delgass wrote:
Actually, iirc, all the drivers actually implement glTexSubImage2D the
same way as glTexImage2D. They always upload the entire texture image --
there was a comment I remeber seeing about the subimage index calculations
being wrong.
On Fri, Jan 31, 2003 at 10:26:13AM -0800, Ian Romanick wrote:
There are two typical ways to go about imporving texture upload
performance in OpenGL applications. One is through the use of OpenGL
extensions. There are several extensions available (or available any
You are talking about
WOULD YOU LIKE TO HAVE YOUR MESSAGE SEEN BY
OVER 15.3 MILLION OPT-IN, TARGETED PROSPECTS DAILY?
Below contains all the information you will ever need to market
your product or service on the Internet.
If you have a product, service, or message that you would like to get
out to Thousands,
On Fri, 31 Jan 2003, Arkadi Shishlov wrote:
On Fri, Jan 31, 2003 at 04:33:36PM -0500, Leif Delgass wrote:
Actually, iirc, all the drivers actually implement glTexSubImage2D the
same way as glTexImage2D. They always upload the entire texture image --
there was a comment I remeber seeing
Arkadi Shishlov wrote:
On Fri, Jan 31, 2003 at 10:26:13AM -0800, Ian Romanick wrote:
There are two typical ways to go about imporving texture upload
performance in OpenGL applications. One is through the use of OpenGL
extensions. There are several extensions available (or available any
Leif Delgass wrote:
I've been looking at the texmem branch and have found a few problems. I
wanted to explain the problems I found and get some feedback before
commiting any changes or putting a patch together.
Thanks for looking over the code. Everyone's been so busy lately that I
don't
Leif Delgass wrote:
There are also a few failing assertions related to placeholder texture
objects. In driTexturesGone, we need to set t-heap = heap or else the
assertion that t-heap != NULL fails in driDestroyTextureObject when
destroying a placeholder.
I see the problem you're talking about
If texture is locked in DRI while rendering, the straghforward solution
is to allocate new texture for every frame or reuse old one from the ring.
The new texture will be free, one application thread can be dedicated to
push texture to AGP and than into the card, while another threads can decode
On Fri, 31 Jan 2003, Ian Romanick wrote:
Leif Delgass wrote:
There are also a few failing assertions related to placeholder texture
objects. In driTexturesGone, we need to set t-heap = heap or else the
assertion that t-heap != NULL fails in driDestroyTextureObject when
destroying a
While I was searching around the net for papers on texture memory
management, I came across some references to Talisman and DirectX 6.0
texture compression. It seems that the compression algorithm used is
called TREC, which is short for Texture and Rendering Compression.
According to the docs, mach64 implements 4:1 VQ de-compression, but
there's no other info. Rage 128 also has a VQ texture format bit,
according to the register header file. Sega dreamcast used a form of VQ
compression also, I think.
On Fri, 31 Jan 2003, Ian Romanick wrote:
While I was
Leif Delgass wrote:
On Fri, 31 Jan 2003, Ian Romanick wrote:
Leif Delgass wrote:
There are also a few failing assertions related to placeholder texture
objects. In driTexturesGone, we need to set t-heap = heap or else the
assertion that t-heap != NULL fails in driDestroyTextureObject when
Coral Calcium will change your Life! Over 157 diseases are caused by calcium deficiency.
Recent research links appropriate calcium levels with the process of aging as
well as many degenerative diseases such as: Diabetes , Arthritis , Heart Disease, Osteoporosis ,Eczema Alzheimer's
Disease,
marivel,
IexeakuasohivpRigmeotaeeixiptáÄ
4DÞ¨¥Ë)¢{(ç[É*.Ç
¢¸ {^®â±á بâ3ââìV¢¹]J¶§dzm§ÿðà ڲíÁªÞr®'^½éfj)b b²ÐëׯzYb²Û,¢êÜyú+éÞ¶m¦Ïÿ+-²Ê.Ç¢¸ ë+-³ùb²Ø§~Ý®'^½é
20 matches
Mail list logo
